Bas Westerbaan wrote: >BoringSSL (Chrome) generates a new keypair for each connection. We do >too. ML-KEM keygen is quite cheap anyway.
That is great to hear! 👍 Hopefully most implementations follow this. Reusing ephemeral keys are bad for several reasons. It relates the key material in different connections that should not be related. A vulnerability (theoretical, bad implementation like no public-key validation, or side channel) can enable an attacker to listen in to a someone's else connections. Reuse also have significant privacy issues as you suddenly have a fixed cleartext field which is the same in several connections. NIST has very good requirements on this "An ephemeral private key shall be used in exactly one key-establishment transaction". Reusing an ephemeral key is not FIPS compliant. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/nist.sp.800-56Ar3.pdf I hope that the CNSA 2.0 Profile for TLS 1.3 will forbid this just like the CNSA 1.0 profile did for IPsec. 3GPP had a lot of help form the CNSA 1.0 profiles. https://datatracker.ietf.org/doc/rfc9206/ I also hope a future update of TLS will forbid reuse. Cheers, John From: Bas Westerbaan <[email protected]> Date: Friday, 1 November 2024 at 13:33 To: Salz, Rich <[email protected]> Cc: [email protected] <[email protected]> Subject: [TLS] Re: MLKEM or Khyber KX BoringSSL (Chrome) generates a new keypair for each connection. We do too. ML-KEM keygen is quite cheap anyway. On Fri, Nov 1, 2024 at 1:11 PM Salz, Rich <[email protected]<mailto:[email protected]>> wrote: Are folks generating a new key every connection or just using a longer-lived keypair and not re-using the random? _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
