ML-KEM in TLS uses an ephemeral keypair from the client, produces using client randomness, and server encapsulation, using server randomness, to generate the shared secret KDF(m|| hash(ephemeral pub key)); it's not just m. Then there is randomness from the rest of the TLS 1.3 schedule, from both parties, as well, to produce the various session keys.
On Wed, Jul 8, 2026, 4:20 PM Nico Williams <[email protected]> wrote: > On Wed, Jul 08, 2026 at 10:06:07PM +0200, Tanja Lange wrote: > > 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. > > Ah, ok, I get it now: the client gets a 32-byte RNG output from the > server during decapsulation. So it's a covert channel, but for active > participants, not for eavesdroppers, but it's real and dangerous. > Whitening the RNG output solves the problem. > > 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]
