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]
