> Date: Wed, 5 Mar 2025 23:50:45 -0600 > From: Jacob Bachmeyer <jcb62...@gmail.com> > > On 3/5/25 23:34, Solar Designer wrote: > > Indeed, HMAC wouldn't be any weaker than its underlying hash on its own > > even when used with a publicly known example key. So I can see how they > > could have (wrongly) expected the same from CMAC. > > If the system is no weaker if the HMAC key is known, then you should not > be using HMAC and you should be using a plain digest instead. (Or am I > missing something? What would HMAC with a known key give you that a > plain digest does not?)
Veering slightly off-topic, but MD hash functions such as SHA-256 are vulnerable to length extension attacks: an adversary's knowledge of a secret message's hash h = H(m) is enough for them to predict the hashes of _related_ messages, h' = H(m || pad(m) || s) for any suffix s. That is, there's an easy-to-compute function f(h, s) = H(m || pad(m) || s). Such attacks can break some protocols. If you use HMAC-H_k(m) instead of H(m), even with a fixed public key k, that defeats such attacks without losing pretty much any other security. So it's not completely bonkers to reach for HMAC with a fixed key. It's a little silly -- you could use H(H(0^d || m)) instead, where 0^d is a hash-length string of all zeros, for the same security, or use SHA-3 or BLAKE2 which address length extension attacks in other ways. Of course, length extension attacks are not relevant to signatures, so it's extra silly to use HMAC under a fixed key for them -- but still not harmful to security. The real problem here is that CMAC is abjectly unfit for signatures.
