[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: replay field size
> From: Theodore Y. Ts'o <tytso@MIT.EDU>
> So, the argument goes that with SHA-1, we can give up some amount of its
> protection against brute-force attacks by shortening it from 160 to 128
> bits (assuming that 128 bits in length is "good enough"), and hopefully
> gaining some protection against the analytic attacks that cryptographers
> might later bring to bear on SHA-1. So this is an engineering tradeoff,
> trading off protection against one attack with protection against
> another. Furthermore, like most engineering tradeoffs, we're working
> with only partial knowledge of how helpful it will really be, versus how
> dangerous it is to allow brute force attacks against the shortened SHA-1
> hash.
Sorry, but this is not an engineering tradeoff. Note that the
cryptographers could just as well have truncated SHA to 128 bits to achieve
this `higher' security. What you are doing is _modifying_ the hash
function. Strictly speaking, this invalidates all earlier analytical work,
and you would have to re-do the entire security analysis of SHA. Note that
a analitical attack that gives collision on only the first 128 bits of SHA
might be possible, in which case the shortening has been very harmfull. My
main argument against shortening is that 128 bits doesn't provide enough
security against brute force attacks in 10 or 20 years time, and I am
assuming that the design life of the protocols is at least 20 years.
> Also note that if someone performs a brute-force attack against one off
> these hashes, they will only be able to break the integrity protection
> for one packet, not for an entire document (as in the case in more uses
> of this technology for digital signatures). In general, the
> requirements for integrity protecting an IP stream aren't quite the same
> as those required for digital signature in commerce.
What are the requirements? I havn't been part of the IPsec discussion, and
I don't have very much time to spend on it, but this seems to be fairly
fundamental. If integrity of a single IP packet isn't so important, then
why bother at all? Of course there are levels of security, but you might
end up doing 99% of all the work, and only getting 50% of the benefits.
BTW, if the hash is used to ensure message integrity, and there is a
separate MAC to ensure authenticity, then you could eliminate the hash. A
MAC provides integrity verification as well, but it doesn't help you
distinguish between a integrity violation and a key-mismatch. Unless
precise error reporting is very important, you could leave the hash out.
Furthermore, the MAC is more efficient, as it requires half as many bits to
provide the same security level (assuming the key is secret of course).
Niels
--------------------------------------------------------------------------
Niels Ferguson, email: niels@DigiCash.com. (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]
Follow-Ups: