As I said back in 2024, when this discussion was actually had (I consider it resolved), hashing a random number generator output defends against one specific failure of an RNG, but not others. In particular, a hash function, like any deterministic function can only ever decrease the entropy of the input, so a RNG with not enough entropy will continue to not have enough entropy (and technically will have slightly less entropy after the hash).
For TLS in particular, this conversation is especially moot, as TLS has client and server random values, that are not usually hashed before being published on the wire. Pretending that this is some sort of failure of ML-KEM is beyond ridiculous. On Wed, Jul 8, 2026 at 1:08 PM Tanja Lange <[email protected]> wrote: > Dear Nick, > In ECDH when you get aG from the server and compute the shared b(aG) you > don't > learn anything about a. > > In ML-KEM the server encapsulates to your ephemeral public key starting > from > some seed m. Decapsulating recovers the seed (and needs to, due to FO). > > In the scenario that the RNG is predictable there is no difference and an > outside attacker gets the shared key in either scenario. Hashing the RNG > output > before using it is at best a band aid. > > In the Dual-EC scenario there is a big difference because ML-KEM gives you > raw > RNG output from the server any time you open a connection to it. > > All the best > Tanja > > On Wed, Jul 08, 2026 at 08:22:51PM +0100, Nick Sullivan wrote: > > I just caught up on David and Sophie's emails and retract my > > suggestion. On the documentation side, both drafts normatively cite > > FIPS 203 for ML-KEM, so its approved-RBG requirement already applies > > and there's nothing to add here. If we don't want to lean on that > > assumption, the fix is uniform entropy hardening at the TLS layer per > > 8446 C.1, not an ML-KEM-specific change. It's the same raw-entropy > > dependency X25519 already has, where the private key each side > > generates has to come from a good source and a predictable one breaks > > it just as thoroughly. So if we want to harden against that, the right > > place is uniformly at the TLS layer per 8446 C.1, not a change to this > > primitive. > > > > Given this, I think the backdoored RNG angle is moot for this draft. > > > > Nick > > > > > > On Wed, Jul 8, 2026 at 7:43 PM Nick Sullivan > > <[email protected]> wrote: > > > > > > I'm pretty confused by this discussion. If the concern is a > > > compromised RNG, can't we just add a quick SHOULD pointing to RFC 8937 > > > and call it a day? > > > > > > The draft references FIPS 203 for the algorithm itself, the > > > Encaps/Decaps definitions and the key check, not as a validation > > > mandate, and it doesn't require an approved RNG anywhere. So a SHOULD > > > on how the encapsulation randomness is generated conflicts with > > > nothing. It sits at the same layer as the "MUST NOT reuse randomness" > > > line already in 4.2, and 8937 just wraps the RNG feeding Encaps, so > > > the output stays an ordinary, interoperable ML-KEM ciphertext. It > > > doesn't touch the primitive. > > > > > > Nick > > > > > > On Wed, Jul 8, 2026 at 5:23 PM Nico Williams <[email protected]> > wrote: > > > > > > > > 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] > > > > _______________________________________________ > > TLS mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
