--On 11 March 2005 00:42 +0000 Roy Badami wrote:

> Collision resistance is another specific property of cyrtographic
> hashes, namely that it is computationally infeasable to construct a
> pair of messages that hash to the same value, and AFAICS NSEC3 doesn't
> actually require a collision resitant hash function.
> Collision restistance implies second pre-image resitance: if you've
> managed to break second pre-image resitance then you have necessarily
> constructed a collision, but second pre-image resitance is a weaker
> property of a hash than collision resitance.

I think there are actually 2 separate requirements:

* Second pre-image resistance - to stop enumeration "the obvious way"
(work backwards from the hashes).

* Collision resistance - to stop a "nit" in the protocol. This is the
one everyone talked about for a ages here. If there isn't collision
resistance, then can't an attacker find QNAMEs with the same hash
value as labels in the zone? If they do this, we are then left with
the problem of what the server should return when a query is made
for that (presumably nonexistant) QNAME. I think the consensus was
to return an NSEC3 record with the identity (1:1) hash. This enumerates
a single label. This isn't dangerous if the main algorithm is
collision resistant.

No caffeine yet so my brain may not work, but I *think* this means
that both collision resistance AND second-preimage resistance are
necessary. I think you are right that collision resistance implies
second pre-image resistance, but I don't think that's the issue
here, as both are required anyway.

You are right in another way though: NSEC3 doesn't (well IMHO shouldn't)
require ANY of those properties of its hash function, UNLESS you
care about enumeration. NSEC3 should be able to cope with ANY function
(whatsoever) as the hash function, though the worse hash function it
is (and the smaller its range is compared to its domain), the more
important a functional fall-back to the identity hash becomes.


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.