Re: AMD Microcode Signature Verification Vulnerability

[Taylor R Campbell <campbell+oss-security () mumble net>]

> Date: Wed, 5 Mar 2025 23:50:45 -0600
> From: Jacob Bachmeyer <jcb62281 () 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.