On Wed, 17 Feb 2010, Eric Rescorla wrote:
On Wed, Feb 17, 2010 at 3:34 PM, Salman Abdul Baset <[email protected]> wrote:
DHTs, however, use a hash function to map resources to nodes, so node-ID
length and hash function output length becomes an issue. The confusion lies
in the ability to use a hash function that emits a greater than 128-bit
value, and then mapping it to the 128-bit node-ID by dropping the most
significant bits. The argument is that by dropping the MSBs, we likely loose
the randomness guarantees which are necessary from the load balancing
perspective. Thus, we are restricted to using a 128-bit hash function for
all DHTs (Kademlia, Pastry, CAN etc). Restricting the use of hash functions
for all DHTs is not necessarily ideal from the viewpoint of future proofing.
Huh?
Any reasonable hash function is just as random in the low-order bits (what you
get if you drop the MSBs) as in the high order bits. This is certainly
a necessary
condition for any cryptographic hash function to deliver the full
security of its
output length.
-Ekr
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.
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.
-s
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
