On 3/5/25 23:34, Solar Designer wrote:
On Wed, Mar 05, 2025 at 11:03:49PM -0600, Jacob Bachmeyer wrote:
[...]
Forging On
We noticed that the key from an old Zen 1 CPU was the example key of the
NIST SP 800-38B publication (Appendix D.1 2b7e1516 28aed2a6 abf71588
09cf4f3c) and was reused until at least Zen 4 CPUs. [...]
They... used... the... example... key... in... a... real...
production... system...
[I have no words.]
It appears they didn't realize the key's secrecy would matter for their
use case (or else they probably wouldn't use CMAC in the first place),
so it "made sense" to stick with a "standard" tested key. Given that
misunderstanding, I wouldn't blame them for choosing an example key.
The purpose of "keys" in cryptosystems is to concentrate the need for
secrecy in a small, easily-guarded value, and assume the attacker knows
everything else about the system.
[...]
The real issue is the use of CMAC without understanding its properties,
not the key choice.
The fact that it is called a "key" (and not a "public key") should be
the hint that it must be kept secret, which means do not use an example
value, just like you do not set your password to "password" or your PIN
to 1-2-3-4-5 unless you really mean to have no security on that system.
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?)
-- Jacob
