[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08)

Hi John,

On 7/10/26 23:31, John Mattsson wrote:
> Hi Nico,
> 
>> 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.

The answer is that the client recovers m from the server because they 
get to pick their own ML-KEM.Decaps() and they control their own ML-KEM 
secret key. FIPS 203 says they do not hash the system random value and 
if your system random value is produced by Dual_EC_DRBG, it is game over 
in many circumstances. TLS compounds the matter and turns that into an 
oracle. This isn't even news, it's what was discussed on the pqc-forum 
three years ago.

Kind regards,
Jacob Appelbaum

> 
> Cheers, John Preuß Mattsson
> 
> From: Nico Williams <[email protected]> Date: Friday, 10 July
> 2026 at 20:55 To: John Mattsson <[email protected]> Cc:
> Jacob Appelbaum <[email protected]>; [email protected]
> <[email protected]>; Tanja Lange <[email protected]>;
> [email protected] <[email protected]> Subject: Re: [TLS] Re: WG Last Call:
> draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
> 
> On Fri, Jul 10, 2026 at 11:07:45AM +0000, John Mattsson wrote:
>> Could you provide a detailed technical explanation of how an
>> attacker controlling the RNG could break ML-KEM but not Kyber with
>> the m �� H(m) step?
> 
> 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`.
> 
> However, as noted, the nonces too need to be hashed RNG outputs to 
> defeat such an attack.
> 
> Of course the attacker could just provide the victim with an RNG
> where the attacker just knows the seed and only needs to know the
> index of RNG outputs corresponding to `m`.  In this case the
> attacker would only have to brute-force a small index, and now
> hashing `m` does nothing to protect the victim.
> 
> So in a way hashing `m` adds no value because if the attacker knows 
> you'll be hashing `m`: since we're talking about an attacker that
> can convince you to use their RNG they can just make you use one
> where hashing `m` achieves nothing.
> 
> But it might be more difficult to switch out the RNG at this late a 
> stage.  On that basis one might recommend some application level 
> whitening of RNG outputs: on the off chance that the attacker was in 
> fact counting on the use of raw RNG outputs for `m` [and nonces].
> 
>> 3. It may be too late now, but I strongly believe RFC8446bis
>> should recommend the use of multiple independent entropy sources
>> to mitigate both accidental failures and intentional weaknesses.
>> RFC 8937 is one way to achieve this, but it is neither the only
>> approach nor necessarily the best one. Many operating systems
>> already combine multiple entropy sources, including keyboard and
>> mouse interrupts, USB events, network and storage timing,
>> scheduler timing, CPU hardware RNGs, TPM RNGs, EFI RNGs, and CPU
>> jitter.
> 
> Indeed.  Even further, apps should do this too on top of what the OS 
> does.
> 
> Nico --

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