On Wed, Jul 08, 2026 at 01:25:50PM -0700, Benjamin Kaduk wrote:
> 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).
>
See, e.g., Botan
https://github.com/randombit/botan/blob/master/src/lib/tls/tls_policy.h
/**
* Hash the RNG output for the client/server hello random. This is a
* pre-caution
* to avoid writing "raw" RNG output to the wire.
*
* There's not normally a reason to disable this, except when
* deterministic output
* is required for testing.
*
* Default: true
*/
their ML-KEM version, true to spec, does not hash the RNG
https://github.com/randombit/botan/blob/master/src/lib/pubkey/kyber/ml_kem/ml_kem_impl.cpp
All the best
Tanja
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
