On Wed, Jul 8, 2026 at 11: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. Hi Tanja, You know, this is a TLS draft. In a TLS 1.3 handshake the server responds to a ClientHello with a ServerHello.random which is 32 random bytes from the Server's RNG. ( Unless HelloRetryRequest is issued. ) Cheers, -markku > > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
