On Wed, 17 Feb 2010, Eric Rescorla wrote:
On Wed, Feb 17, 2010 at 4:38 PM, Salman Abdul Baset
<[email protected]> wrote:
Unless I misread your earlier post on this list, there may be a possibility
of a collision attack. Although, as you pointed, it is a preimage resistance
issue.
Again, huh?
The collision resistance of a b bit hash function is approximately 2^{b/2}.
The collision resistance of the first (or last, or any) b' bits of a b bit
hash function is approximately 2^{b'/2}.
Rather than arguing about hash function properties, I think the most
future-proof solution is:
-fix a hash function for the mandatory-to-implement DHT, which is already
there in the draft.
-allow a large size hash function and corresponding length node-IDs to be
used per overlay, by specifying them in the configuration file.
I don't understand why this is superior. Again, what's wrong with just having
fixed size node-IDs which are created by truncating a hash?
Flexibility and future-proofing.
If we want to keep the 128-bit node-IDs, then we need to clarify in the
draft that they can also be obtained by trucating a >128-bit hash function
without worrying about collisions. For example, this will be helpful for
someone who may notice the node-ID length difference between the original
Chord paper and RELOAD Chord. We also need to clearly state that such a
truncation is applicable for any DHT (Kademlia, Pastry, CAN) and not just
Chord.
-s
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
