> > 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! > > More vitally it allows people that've heard and the hash of the message "Give:john:coin:20" to create AND SIGN the message "Give:john:coin:20000000". It's a bit of an unusual attack though, especially since we usually have length fields. It could push other data out of the message though. It really depends on the protocol. I certainly scratched behind the ears when I read this. There was a paper on authentic cookies without server side state: take the cookie's content, append a secret, hash it and put the hash after the rest of the cookie. If you put data in a sort of URL-encoded manner into the cookie that creates a large potential threat.
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. I wasn't around for that competition. SHA3 certainly isn't "urgent" for the industry, if they need more security they usually just enlarge n (more bits) and it'll quickly suffice. Being proactive is very nice though. Adaptation of anything is usually really slow. Having SHA3 around in a tested and production ready state will increase our security more than it has to? Great. Lewis
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
