|
A lot of hash functions, including the SHA-2 family(but not the SHA-3 candidates and SHA256d) are vulnerable to length extension attacks. But when is this property a problem? I guess certain naive MAC implementations might have issues. Are there also some situations where length-extensions cause problems for unkeyed hashes? |
||||
|
|
|
The archetypal situation where the length-extension property becomes problematic is when ones builds a Message Authentication Code from a hash function as $$BadMAC(K,M)=Hash(K||M)$$ where $K||M$ is the concatenation of the Key and the Message. The length extension property then translates directly into the capability to forge a different message, starting as the original, for which computing the $BadMAC$ is trivial. In practice, that could allow adding an appendix to a text protected by $BadMAC$ (after a short rash of garbage in most cases, but often it could be invisible when printed). Also, that could allow extending the size of a short signed message so that it creates a buffer overflow after its integrity is checked using $BadMAC$. HMAC is secure against that; and then more. The length extension property obviously allows to obtain many more hash collisions from a single one. If SHA-1 was experimentally broken with just one collision found (due to the high cost of the attack), the collision property would make that one-time attack a more immediately damaging issue. That's especially true if the collision was devised so that the colliding messages (of same length) start with an appropriate code header (which likely requires no more work than any other collision): it would be possible to generate, at low computational cost, two programs with the same SHA-1 but any two different behavior. Another (artificial) example could be when it is asked the hash of increasingly long messages (with precisely the wrong content) as a Proof-Of-Work: one user knowing the hash constituting the POW of a user could abuse that into another POW indicative of slightly more work. |
||||
|
|
