On Wed, Jul 08, 2026 at 10:06:07PM +0200, Tanja Lange 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.
I think it may be important to highlight the distinction between the safety of the TLS connection and the safety of a given endpoint, especially in light of Dual-EC type scenarios. It seems like the question of whether 'm' is hashed is really about the latter and not the former. That is to say, the construction of the TLS handshake, with both parties contributing randomness that's included into the handshake transcript, gives a strong key for the connection as long as at least one participant is honest and has a strong RNG. However, in a scenario where one endpoint has a Dual-EC-style compromised RNG, where seeing enough of its output would allow an attacker to reconstruct RNG internal state and predict subsequent output, exposing a lot of RNG output either in plaintext on the wire or from server to client (since the client initiates connections, exposure from client to server is a less severe vector) can lead to risk to that endpoint's security, not just on this connection but on future connections as well. In the scenario under discussion here, an unhashed 'm' would be exposed to the client, thus potentially exposing server RNG state to the client but not to a passive observer. However ... is it really plausible that the ML-KEM 'm' would use a compromised RNG but not the (plaintext on the wire) ServerHello.Random? If they use the same RNG then it seems the incremental risk to a server with compromised RNG from using ML-KEM is zero, because ServerHello.Random already leads to an equivalent exposure (of 32 bytes of RNG output). -Ben _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
