Thank you, David. We did mention this rationale in the paper. However, it demonstrates that an attacker can use *m* and *pk* to *derive sk*. In a compromised software supply chain (for example, a SolarWinds-class attack), this could have serious consequences for any protocol relying solely on ML-KEM. It is possible that hybrid deployments may offer greater resilience while these APIs remain accessible for testing. Predictability of *m* could also arise if virtual machine images are created or deployed with insufficient entropy which is happening in scale ups under load. There are also scenarios in which the pseudorandom entropy available to the Linux DRBG may be compromised and boiled down to brute force for min-entropy, making *m* predictable for a window and potentially undermining the security assumptions of the scheme for non-hybrid systems.
The threat model is not expected to be permanent and will likely be addressed in future implementations when testing pathway is closed. For the time being, however, I do not support standalone ML-KEM On Tue, Jul 7, 2026 at 17:28 David Benjamin <[email protected]> wrote: > This paper seems to amount to being concerned about something that is > standard practice in testing non-deterministic cryptographic processes: you > should have a defined, deterministic process from explicitly-passed > entropy, because that makes testing possible. > https://words.filippo.io/avoid-the-randomness-from-the-sky/ > > As it's standard practice, this is not unique to ML-KEM. In X25519, the > equivalent of the encapsulation coin in ML-KEM is the X25519 private key > that each side generates. That too needs to come from a secure source of > randomness. At the same time, you'll find that every implementation > provides *some* deterministic version of this API. This is both for > deterministic testing and because that's how you import a serialized > private key. Indeed, because of the latter, you will not see any kind of > testing guard on it. X25519 depends on the caller knowing the difference > between importing and generating a key. > > For example, see this API where both computing the public key and the > Diffie-Hellman operation itself just take the secret as an explicit > parameter. Should one predictable entropy in there, the system would also > break. > https://cr.yp.to/ecdh.html > > This does not seem to be a reason to be concerned about ML-KEM over any > other algorithm. Calling the correct functions in your TLS stack, and > making sure an attacker cannot modify your TLS stack to call the wrong > functions, is part of the baseline for everything here. > > On Tue, Jul 7, 2026 at 11:39 AM Mark Tehrani <[email protected]> > wrote: > >> Dear all >> >> I do not support the publication of this document. Defense in depth is >> clearly needed, implementation of algorithms are in the standardization >> process and therefore they may have implementation immaturity. My example is >> here: >> >> https://eprint.iacr.org/2026/1117 >> >> Best, >> >> Mark Tehrani >> Founder & CEO >> CyberSeQ Ltd (UK) >> +44 7818 712279 <+44%207818%20712279> >> [email protected] >> https://www.cyberseq.io >> >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
