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]
