Eric, Can you say why this statement is true: > the > cryptographic security requirements that dictate the current set of > hash function sizes aren't really the same as what we need here
Are you saying that collision resistance doesn't have to be that strong for NodeIDs? Furthermore, by fixing the NodeID length at 128 bits, are you making a statement that there will never be a need for greater collision resistance? Bruce Davie On Jun 18, 2008, at 10:56 AM, Eric Rescorla wrote: > At Wed, 18 Jun 2008 07:34:24 -0800, > Michael Chen wrote: >> >> Cullen, >> >> Having the same NodeId size on the wire as in computing memory makes >> programming much easier. > > Without addressing the generic question of whether NodeIds should be > variable length, I don't really think the appropriate size of NodeId > is that related to the size of the hash function you happen to be > using to convert Resource names to Resource-Ids. Obviously, the size > of the hash function ought to be large enough to fill the entire > Resource/Node-Id space, but, the converse is not true. Moreover, the > cryptographic security requirements that dictate the current set of > hash function sizes aren't really the same as what we need here. If > you're using, say, SHA-256, it's trivial to have it emit a 128-bit > value simply by truncating. If you like, you can think of this as a > new hash function called "SHA-256-truncated-to-128". > > -Ekr > > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
