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

On Wed, Jul 08, 2026 at 04:04:34PM +1000, Viktor Dukhovni wrote:
> On Tue, Jul 07, 2026 at 10:27:56PM -0700, Christian Huitema wrote:
> > I just read Jacob Applebaum's message. Given his description of the
> > late-standardization suspicious change that looks like a backdoor in the
> > ML-KEM specification, I agree with his conclusion. The WG should not ask for
> > publication of the current graph, not until the changes requested by Jacob
> > are made.
> 
> The removal of whitening of the `m` random input to Encaps is not a
> plausible backdoor.  If all you have is a broken RNG, you're free to
> apply whitening to obtain a new less bad RNG and use that instead.

Furthermore, `m` is not a covert channel as Jacob said because it
doesn't go in the clear on the wire.  Since `m`'s confidentiality is
critical to the security of ML-KEM, if `m` leaked in a covert channel,
that would destroy ML-KEM's security, but that's why `m` is part of the
construction of ML-KEM's `ct` payload, and it gets encrypted to the `pk`
along the way, and then the peer doesn't surface `m` to the application
either, therefore:

 - no eavesdropped gets to see `m`

 - `m` is not a covert channel

 - hashing or not hashing the RNG output that gets used as `m` makes no
   difference and nothing can be leaked due to not hashing it

And being a KEM, the two parties both contribute entropy, so a poor
choice of RNG on the server will not compromise the whole session.

But let's say one wants to hash the RNG outputs, then what has one
achieved?  This: that one has merely altered the RNG design.

Nico
-- 

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