[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08)

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]