On Wed, Mar 05, 2025 at 11:50:45PM -0600, Jacob Bachmeyer wrote:
> On 3/5/25 23:34, Solar Designer wrote:
> >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.
... or you mean not to use this specific authentication factor, relying
on some other(s) - like the console being protected physically. A risky
thing to do ("what can possibly go wrong?"), but the analogy is there.
> >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?)
My point is that sometimes a building block you readily have or can
create most cheaply provides excessive functionality, or so they
thought. Perhaps they could implement CMAC-AES easier than implement
SHA-256 (if they already had AES, but not yet SHA-256), and thought it's
as good as an HMAC.
Alexander
