This is a discussion on Re: Minor editorial NSEC3 comments - DNS ; --On 12 March 2005 03:24 +1100 Mark Andrews wrote: >> 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 ...
--On 12 March 2005 03:24 +1100 Mark Andrews
>> 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.
> Not quite ANY function. The size of the hash space must be
> bigger than the number of records in the NSEC3 chain.
Correct - I said I hadn't had enough caffeine - else you cannot create the
signed file in the first place. In fact the requirement is stricter than
that: the function must, with a suitable salt value, produce unique[*]
values for each record in the NSEC3 hash chain, and it must be possible to
find such a salt value with a reasonable period of time. Of course having
the range of the hash function larger than the size of the domain of the
existent input values (as you suggest) is a necessary condition, but it is
not sufficient. Trivial example:
H(x) = SHA-512(x, salt) if x is even
1 if x is odd
Such a hash function satisfies your criterion, but is no use.
[*] note that this type of potential collision between hashes of
two existent labels is entirely different from the label / QNAME
collision problem - I know you know that, this is for the benefit
of those reading the archives...
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.