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

Hi Nico,

On 7/10/26 20:54, Nico Williams wrote:
> 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`.

With a lot of respect, no. Attacking the seed again confuses the issue. 
The attack works without knowledge of the Dual_EC_DRBG seed.

> 
> However, as noted, the nonces too need to be hashed RNG outputs to
> defeat such an attack.

There are two parts: ML-KEM and TLS. For ML-KEM, we only need a single 
ML-KEM.Encaps() that samples from the system RNG where the RNG is 
Dual_EC_DRBG in hardware or software, and then we can reconstruct the 
RNG's internal state by attacking `m`. If `m` is the usual truncated 
Dual_EC_DRBG output then we only have to do a small amount of work to 
recover (~2^16) the internal state.

> 
> 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.
> 

This is speculative and distracts from the actual attack I have 
described in painstaking detail.

> 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.
> 

Bouncy Castle ships Dual_EC_DRBG today and it contains the original NIST 
parameters that are understood to be an NSA backdoor.

I urge you to evaluate the attack against this example which is a 
reality and can be installed with a single package on Debian or Ubuntu. 
It even has a nice feature of allowing you to set your own parameters in 
place of NIST so you can simulate attacking Juniper's ScreenOS backdoor 
Dual_EC_DRBG fiasco in just a few lines of code.

I am happy to share code if this in doubt. Please contact me off list.

> 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.
> 
The fast key-erasure RNG design is a nice example of how to do this safely.

Kind regards,
Jacob Appelbaum

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