Subject: RE: nsec2 large label pain

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 24 May 2004 10:39:00 -0700

> > There are other obstacles as well. Current label length 
> restricts the
> > message digest size (if represented in hex) to 248 bits. 
> This excludes
> > functions like sha-256/384/512.
> 
> If we forget hex (with a byte-utilization rate of 50%) and do kind of 
> base64 (75%), then sha-256 can still be used.

There are two issues, strength of algorithm and the risk of attack.

It may well be better to use SHA-256 and truncate to some length than to use
SHA-1. From a purely cryptographic point of view SHA-256 is a much better
scheme, it is also likely to be supported better in future hardware
acceleration etc.

Rather than use hex I would use BASE32 encoding, several people have
proposed schemes that use ten numbers and 22 characters as a case-proof
symbol set. This means that you get five bits per character rather than
four. So a 160 bit digest is only 32 characters.

How long should the digest be? Since we are using it to mask a label 
that is itself bound in size we don't need very many bits at all. 

In fact the size of the range of the hash need only be the square of
the size of the domain.

I don't think it very likely that we will have individual zones with more
than 2^64 different labels. So the probability of collision will be
negligible if have a hash with 2^128 bits.

If label size is an issue we could argue over likely domain sizes etc.

		Phill

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 24 May 2004 10:48:58 -0700

> > future when a longer hash string becomes essential. 
> Remember it wasn't
> > long ago that MD5 was the flavour-of-the-month hash 
> function. Who's to
> > say if SHA-N won't suffer the same fate in a couple of years?
> 
> In the worst case, SHA would be flawed and its output size 
> would play no 
> role...
> NSEC2 already offers provisioning for alternative hash types.

From a pure algorithm perspective the concern here is that MD4 is
broken, MD5 is deeply compromised and both MD5 and SHA-1 are both
incremental advances on MD4.

I have no reason to doubt the security of SHA-1 at this time,
but we are past the point where it is appropriate to use it
in a NEW specification environment. The whole point of AES was
to address these issues industry wide.

The length of the algorithm output is not an issue, both SHA-1 and 
SHA-256 provide more than sufficient bits. We should probably 
truncate in either case.