Re: Re: [PATCH] crypto: krb5 - Use constant-time checksum comparison

[Jiangshan Yi]

On Thu, Jul 30, 2026 at 05:04:17PM +1000, Herbert Xu wrote:
> Please explain exactly what secret information might be leaked by
> the timing attack.

Hi Herbert,

Thanks for the review and the question.

The leaked secret is the correct MIC checksum value, not the key Kc
itself.

In rfc3961_verify_mic(), memcmp() compares:

  - cksum:  the correct MIC = MIC_{Kc}(metadata || data), computed
            with the session checksum key Kc
  - cksum2: the claimed MIC from the incoming packet (attacker-controlled)

memcmp() returns at the first mismatching byte, so its timing reveals
how many leading bytes of the attacker's guess match the real cksum.

Because Kc is fixed for the session and the attacker chooses the
message M, the target cksum is a constant across repeated attempts.
The attacker can then recover it byte by byte: try all 256 values for
cksum2[0], observe which takes longest (meaning it matched and
memcmp proceeded to the next byte), fix it, repeat for cksum2[1],
etc. Once cksum is fully recovered, submitting (M, cksum) passes
verification -- a forged MIC.

Kc itself is not exposed, since cksum is a one-way function of Kc.
But recovering cksum is enough to defeat integrity for that message,
which is the secret worth protecting with constant-time comparison.

This matches what krb5enc.c:255 already does with crypto_memneq() for
the equivalent comparison.

If you agree this justifies the change, I will resend with this explanation folded into the commit message.

Thanks,
Jiangshan