On Fri, Jul 10, 2026 at 09:31:35PM +0000, John Mattsson wrote:
> >Suppose the RNG outputs 32 byte outputs where the first 40 bits are an
> >index that can be used by the attacker to recover the remaining 216 bits
> >when the attacker also knows part of a seed for the RNG.  In this case
> >the attacker must see those 40 bits in order to recover the remaining
> >216 bits, but hashing means they will not see them and will have too-
> >large a work factor to recover the original `m`.
> 
> This seems like an excellent description of how hashing could help
> when applied to ServerHello.random. However, the server_share does not
> contain m; it contains only the ciphertext c (or c || K_B in the case
> of X25519MLKEM768). Therefore, I do not see how the additional step m
> ← SHA3-256(m) would help, even with a static ek, and even less so with
> the ephemeral ek used in TLS. It is also worth noting that, in ML-KEM,
> m is hashed before it is used. The difference compared to Kyber is
> that ML-KEM does not hash m twice.

But the attacker -now an active attacker acting as a client- would
recover `m` and thus learn about the server's RNG's state, then apply
that knowledge to compromising _other_ sessions where the attacker is
passive (i.e., has recorded those sessions as an eavesdropper).

Again, hashing `m` won't defeat an attacker who can find other ways to
compromise your RNG, but if it's too late for them to do so now then
hashing (or otherwise whitening) the RNG's outputs then why not?

The "answers to why not hash `m`?" [and my retorts] are:

 - it might decrease entropy

   [I don't think this is a problem.]

 - the nonces and other KEMs and ECDH / hybrids all have this problem
   anyways so why focus on ML-KEM and make it the baddy?

   [Telling TLS implementors more generally to whiten their RNGs'
   outputs seems like a good idea.]

 - hashing `m` won't defeat all RNG-based attacks

   [True!  But it will defeat _some_, therefore it seems worth doing.]

Are there other answers?

Nico
-- 

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to