Re: replay field size

[Niels Ferguson <[e-mail]>]

> From: Michael J. Oehler <[e-mail]>
> 3. Truncate the SHA-1 to 128 bits
>         The format for MD5 and SHA will then be identical.
I'm a bit concerned with all the people that are happy to truncate hash
values to shorter sizes. This should only be done if there is a thorough
understanding of the threats and desired security level. In particular, SHA
has a 160 bit output _because_ a 128-bit output was deemed too short. If
you truncate SHA to 128 bits, the work effort to create a collision goes
down from 2^80 to 2^64.

Depending on the design lifetime of this stuff, 2^64 probably isn't enough,
and one could question the wisdom of limiting the future security to 2^80
operations. Is there really such a shortage of bits that we have to reduce
bitcounts everywhere? 

In general, 128-bit hash values are safe enough at the moment, but will
probably be insecure in the forseeable future. MAC codes, which are
computed with a shared secret key, can generally be truncated to half the
length of the hash; but this all depends on a detailed analysis of the
protocols.

One other note: complexity is one of the major enemies of security. Most
security systems fail because of bugs, and the number of bugs grows with
some high order of the complexity. So let us try to avoid complexity
wherever possible. In particular, negotiated field length add complexity to
save a few bits. Is this worth it?

Niels

--------------------------------------------------------------------------
Niels Ferguson, email: [e-mail]. (usual disclaimer applies)
  ...Of shoes, and ships, and sealing-wax, of cabbages, and kings,
  And why the sea is boiling hot, and whether pigs have wings... [Carroll]