On Wed, Feb 17, 2010 at 5:23 PM, Salman Abdul Baset <[email protected]> wrote: > 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.
I have no problem with adding this clarification. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
