[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    Re: NSEC3 Issue 27: creating a flag octet.
From:       Alex Bligh <alex () alex ! org ! uk>
Date:       2006-10-23 18:21:38
Message-ID: 00566F287A0A22E64859506B () [192 ! 168 ! 0 ! 101]
[Download RAW message or body]

Wouter,

>> My assertion is that to the extent that the above is a problem,
>> it can be fixed by mixing in the original hash value. So we have
>>  H(x)
>>  H(H(x)^x)
>>  H(H(H(x))^H(x)^x)
>>  H(H(H(H(x)))^H(H(x))^H(x)^x)
>> now in case that looks like a lot of memory storage, note that the term
>> which is mixed in is simply the previous result. Now we know from our
>> assumptions above that the ^ operator's range is no less than the the
>> larger of its input domains. This means (taking the last example) that
>> the range of the outer hash function is no less than the range of H(x).
>> Hence the range of the overall function has not been substantially
>> reduced (i.e. not reduced more than a single H(x) application)
>
> I agree and disagree. I agree the ^ operator does not reduce range. It
> does not _increase_ the range either. It does alter every value to one
> other value, which is nice. Taking a set of values and Xoring them (or
> so) makes all values different, but you end up with the same number of
> elements in your result set.

Ah, but you end up with the same number of elements in your result
set as the LARGER of the two sets (x), not the smaller H(x). So the
input to the second H() is as large as (x), not merely as large
as H(x). This is the point where our logic diverges.

Anyway, it looks like we need not do this (even though it's harmless
in my opinion).

> Even if I'm wrong, lets go for 1 octet flags, 2 octets iterations? It is
> then less optimally encoded, but so very easy to use.

Yes I think in practical terms this works, and Roy seems happy with it.

I'm wondering if we should have a security considerations entry which
says something to the following effect.

	It may be theoretically possible to select a hash algorithm which
	would be otherwise suitable for the purpose but whose range is
	reduced significantly by repeated iterative application. Such a
	hash function would be more likely to suffer collisions with a high
	number of iterations. No currently defined hash functions are known
	to the authors to degrade significantly with practical numbers of
	iterations. However, this consideration should be borne in mind
	when selecting new hash functions.

Alex

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
[prev in list] [next in list] [prev in thread] [next in thread]