4 ms·
This is a nice writeup on length-extension attacks, although I wish it had placed the takeaway further up: `H(s || m)` is almost always the wrong signature cons
by woodruffw 3y ago
This is a nice writeup on length-extension attacks, although I wish it had placed the takeaway further up: `H(s || m)` is almost always the wrong signature construction, even if the hashing function itself doesn't enable length extension attacks. You almost always want an HMAC.
- jupiter_flyby 3y agoNeither mention truncated hash
- jakear 3y agoYa, SHA384 is the way to go. By discarding some bits, the internal state isn’t public and length extension becomes impossible.
- AtNightWeCode 3y agoThis is my understanding as well but I have seen claims that it is still very possible to do length attacks on SHA384.
- jakear 3y agoAny reference for that? Based on the wiki it has 128 bits of security against length extension. https://en.m.wikipedia.org/wiki/SHA-2 https://en.m.wikipedia.org/wiki/SHA-2
- oconnor663 3y ago> even if the hashing function itself doesn't enable length extension attacks My impression was that H(s||m) was reasonable with e.g. SHA-3, assuming you have a fixed key size. The only downside I can think of is that you have to remember not to do it with variable length keys or with SHA-2. Am I missing something?
- xeeeeeeeeeeenu 3y agoIt's not unreasonable, although in the case of SHA-3 (Keccak), it's recommended to use KMAC. It pads the key and adds a domain separation prefix. Unlike HMAC, there's no double hashing. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...
- espadrine 3y agoI’ve seen recommendations to use HopMAC (roughly H(key, customization=H(message))), to thwart differential power analysis, reducing the need for protection to the shorter outer call: https://www.reddit.com/r/crypto/comments/llaqim/comment/go1w9dl/ https://www.reddit.com/r/crypto/comments/llaqim/comment/go1w...
- gnabgib 3y agoKangaroo12(K12) is a reduced-round KECCAK(aka SHA3) hash. Their HopMAC recommendation is only for K12 (and presumably Marsupilami14), not general purpose like HMAC (it's also quite similar to HMAC[0]). There's also KMAC[1] which is based on full-round KECCAK, avoiding the double hash. HopMAC(K,M)=H(K || H(M)) HMAC(K,M)=H(K || H(K || M)) [0]: https://datatracker.ietf.org/doc/draft-irtf-cfrg-kangarootwelve/ https://datatracker.ietf.org/doc/draft-irtf-cfrg-kangarootwe... [1]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...
- wongarsu 3y agoEven if it's not required, the HMAC construction seem to generally make it much harder to exploit any weaknesses in the hash algorithm. For example SHA-1 is pretty broken by now, but HMAC-SHA1 has proven pretty resilient. (obviously don't use HMAC-SHA1, but it has hung on pretty well considering the state of SHA1)
- tptacek 3y agoAre we saying anything other than that preimage resistance on SHA1 has held up? Because that's true of MD5 too. It seems probable that H(k,m), for truncated H, will hold up? The big reason I can think of not to use H(k, m) (or hand-rolled SHA3 KMAC) is that it will quietly fail open if you switch to a normal SHA2 hash.
- erhaetherth 3y agoWhat is || in this scenario? I only know it as logical OR.
- gslin 3y agoconcatenate strings.