Eric,
A very helpful and clear answer, thanks.
Bruce
On Jun 18, 2008, at 8:19 PM, Eric Rescorla wrote:
> 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
