On 10/04/12 02:40 AM, Marsh Ray wrote:
On 04/09/2012 07:00 AM, Jeffrey Walton wrote:
http://h-online.com/-1498071
none of the five finalists are affected by known attacks on MD5,
SHA-1 and SHA-2 and the Merkle-Damgård construction on which all
three are based.
Well, gee, isn't that enough?
Not really. When the AES competition was run, it was because DES was on
its last legs in both cryptographic terms and protection/utility terms.
In contrast, SHA1 is closely challenged in cryptographic terms, but
still no prize, and SHA2 seems light-steps away.
Further, from a cryptographic pov, these might be exciting results, but
from an engineering perspective, ho hum ... yawn? Protocols rarely
depend solely on the hash algorithm for their integrity, there is a lot
of fat built in to most designs. And, we've known to do this for a long
long time, e.g., to introduce nonces in signed designs.
True, one thing we've learned from the SHA-3 competition is that
SHA-2 is surprisingly good. It has held up to the collision attacks
that have plagued previous SHAs better than most had hoped. It turns
out to be quite efficient on modern 64-bit CPUs for long messages
when compared to the SHA-3 designs of similar strength. In
comparisons of hardware efficiency (i.e., throughput per gate) SHA-2
appears as good (or better) than the SHA-2 finalists.
But as SHA-2 is still a pure Merkle–Damgård construction it deviates
from an ideal pseudorandom function or random oracle in a couple of
ways.
Firstly, and most significantly, it is subject to length extension
attacks. This means that given a hash value of some secret message,
we can compute the hash value of that message with our own chosen
plaintext appended without needing to know the original message. This
is surprising to many protocol designers!
Well, that's a surprise to me. But on reflection, the reason it is a
surprise that I (we?) never considered that feature is because we would
never ever rely on it. It's like saying, oh, gosh, we can use SHA1 to
protect against buffer overruns! Happy Days!
HMAC with a secret key is supposed to be a mitigation for this, but
it is not magic pixie dust. The SSL 3.0 and TLS 1.0 - 1.2 protocols
get it wrong:
http://tools.ietf.org/html/rfc5246
7.4.9. Finished verify_data PRF(master_secret, finished_label,
Hash(handshake_messages)) [0..verify_data_length-1];
The PRF is based on HMAC, but by performing an MD5/SHA-1 on the
messages before supplying the result to the HMAC message input it
re-introduces the extension attack. I don't think this translates
into a vulnerability in TLS but it's a bit too close for comfort.
Additionally, there are:
Joux muticollisions "Multicollisions in Iterated Hash Functions.
Application to Cascaded Constructions"
http://math.boisestate.edu/~liljanab/MATH509Spring2012/JouxAttackSHA-1.pdf
Herding or "Nostradamus" attacks http://eprint.iacr.org/2005/281
Second preimage attacks "Second Preimages on n-bit Hash Functions for
Much Less than 2^n Work"
http://www.schneier.com/paper-preimages.html
These are all closely related and have a basis that the attacker is
able to find that first collision, something that we hope will never
happen with SHA-2. But the manner in which other important security
properties deteriorate rapidly after that first collision is found
represents a deviation from ideal behavior.
My understanding is that the SHA-3 finalists address these issues.
Meanwhile, notwithstanding excitement nearly a decade ago now, SHA1
still chugs on. And software engineering's got your back.
That's not to say that the SHA3 comp was unneeded. But it wasn't the
same level of necessity that AES had.
iang
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
