On Thu, Jul 09, 2026 at 08:17:36AM +0200, Tanja Lange wrote: > > On Wed, Jul 08, 2026 at 01:25:50PM -0700, Benjamin Kaduk wrote: > > > > 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://urldefense.com/v3/__https://github.com/randombit/botan/blob/master/src/lib/tls/tls_policy.h__;!!GjvTz_vk!SPz_kT_rGAVH4ZaUhKlgChenbkLtKaxRKPQ0r3qIIUjwNT6F6y6JlG_5QrFDNaPI0223gTgA3_av0b7BfA$ > > > /** > * 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://urldefense.com/v3/__https://github.com/randombit/botan/blob/master/src/lib/pubkey/kyber/ml_kem/ml_kem_impl.cpp__;!!GjvTz_vk!SPz_kT_rGAVH4ZaUhKlgChenbkLtKaxRKPQ0r3qIIUjwNT6F6y6JlG_5QrFDNaPI0223gTgA3_ZIxUHrkQ$ >
Ok, thanks for the reference! I think I remember some discussion in the lead up to RFC 8446 about having separate "public" and "private" RNGs as a possible option but that did not make it into the final RFC (instead we have Appendix C's guidance to just use a good RNG everywhere), so I guess I had internalized the result of that discussion as "best practices". -Ben _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
