On Wed, Jul 08, 2026 at 11:22:54PM +0300, Markku-Juhani O. Saarinen wrote:
> On Wed, Jul 8, 2026 at 11:08 PM Tanja Lange <[email protected]> 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.
>
>
> Hi Tanja,
>
> You know, this is a TLS draft. In a TLS 1.3 handshake the server responds to a
> ClientHello with a ServerHello.random which is 32 random bytes from the
> Server's RNG. ( Unless HelloRetryRequest is issued. )
>
> Cheers,
> -markku
>
Dear Markku,
Thank you. I'm aware of the context.
In our Dual-EC paper (earlier TLS versions) we got the raw Dual-EC output from
"session ID" and "server random", see
https://projectbullrun.org/dual-ec/index.html
for more details than you're asking for.
Protecting against such issues is why there is RFC 8937.
https://www.rfc-editor.org/rfc/rfc8937.html
If you implement your TLS 1.3 server with the best precautions you don't drop
raw randomness at the protocol level.
All the best
Tanja
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
