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

Hello Thom,

On 7/8/26 11:52, Thom Wiggers wrote:
> Hi,
> 
> ML-KEM is arguably not backdoorable unless you break the RNG. Bad
> RNG is something that we can’t really protect against anyway.

We can easily protect against this exact concern with a single hash 
function call over the system randomness.

After that fix is applied, we can return to the regularly scheduled 
lattice security assumption concerns. I look forward to seeing further 
discussions on power-of-two cyclotomics as Tanja Lange mentioned in her 
earlier email.

My point about the hash over `m` is that we should ensure that the 
lattice related security assumptions in the cryptographic primitive are 
the relevant security assumptions!

ML-KEM's security does not require `m` to come directly from the system 
RNG without hashing, and it does no harm to hash `m` at all except to 
users of the covert channel. It will stop this very specific 
exploitation technique. The computational cost is minimal and literally 
all of the computational cost is wasted if the covert channel is used.

> Classic cryptography is also broken if the RNG is busted.

Sure, kinda, maybe, usually. Oddly though: X25519 probably does not fall 
from this specific kind of RNG sabotage unless ML-KEM leaks the 
sabotaged RNG state first because it is not a lack of entropy but a 
covert channel. It is unfortunate that (many) implementations of TLS 
(1.3) tend to write system randomness directly into randomized fields 
which is then visible on the wire to a passive adversary.

Consider why the Extended Random draft was desirable from an adversarial 
perspective: leaking the sabotaged RNG state allows for side stepping 
the fundamental hardness assumptions of the cryptographic primitive 
protecting the contents of the protocol run.

> Finally,
> the TLS key schedule still mixes in all messages from both sides
> rendering the point moot for TLS.
This response suggests a misunderstanding of how large-scale adversaries 
will exploit the issue that I have described.

Kind regards,
Jacob Appelbaum

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