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]
