At Wed, 18 Jun 2008 18:05:30 -0400,
Bruce Davie wrote:
>
> 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?
There are some separate issues here:
Node-Ids:
NodeIds aren't generated using the hash function, except in the
(basically unsafe) self-signed certificate mode. In the central
enrollment server mode, the enrollment server can easily ensure
uniqueness by simply keeping a table of all the ids it has issued.
Even if it didn't do that, getting a collision would presumably
require an impractical (order 2^64) queries to the enrollment server,
which you would think it would notice.
Even in the self-signed mode, it's not clear that collision
resistance is the relevant property, since a collision would
presumably let you generate multiple certificates for yourself
with the same NodeId. It's not clear that's useful, and
since we base the NodeId on the public key anyway, and
there's no prohibition on using the same key for two certs.
So, even in this case, I think the relevant issue here is
preimage resistance, which, as you know, scales as 2^N rather
than 2^{N/2}.
Resource-Ids:
By contrast, resource-ids are generate by hash functions.
However, again it's not clear that it's a useful attack
to generate two resource names that hash to the same
resource id, since that just creates a collision on your
own data. What you want again is a preimage so you can
attack someone else's data.
So, it may be the case that there's a collision attack, but
it's not clear to me what it is.
-Ekr
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
