Thank you, John. You are right. NIST has certainly done the right thing. My concern is the practicality of implementation in the AI era, which empowers exaggerative narratives like mine to become economically feasible.
Entropy failures have been a story for more than two decades. I have never claimed any novelty; on the contrary, I have documented the history of such failures here: https://github.com/owlmt/in_quest_of_entropy/blob/main/README.md For VM scale-ups, e.g. Kubernetes deployments, or even heavy-duty workloads like NVIDIA cuPQC running on GPUs, we currently rely solely on the Linux DRBG state. One example is available here: https://github.com/owlmt/in_quest_of_entropy/blob/main/cuPQC/results/RESULTS.md Therefore, relying on pure ML-KEM and its dependence on the random value *m* is, in my current understanding, equivalent to assuming that adversaries will never be capable of compromising the Linux RNG, for example, through a memory attack against the Linux randomness *crediting process* of real entropy or by exploiting similar weaknesses. To me, that underestimates the future capabilities of AI-assisted adversaries, which could eventually reach a Mythos-level capability against FOSS projects such as the Linux kernel. Thank you both(David and John) for your feedback. On Tue, Jul 7, 2026 at 6:16 PM John Mattsson <[email protected]> wrote: > Agree with David > > I think this is a largely unsurprising implementation survey wrapped in an > extremely exaggerated security narrative. The fact that a randomness > compromise, an attacker-controlled RNG, or an attacker with code/build > control break security is neither new nor surprising, nor is it specific to > ML-KEM. The comparison with Dual_EC_DRBG is particularly misleading. > > The one genuinely useful point in the paper is that some libraries expose > internal functions. However, in the case of ML-KEM, these interfaces do not > appear to give an attacker any capability that they could not implement > themselves. The main concern with exposing the internal ML-KEM interfaces > is that developers may misuse them. > > NIST seems to have done everything right, they listened to feedback from > the cryptographic community and followed current best practices for > designing cryptographic interfaces including making the distinction > explicit by naming the functions _internal() and _external(). > Cheers, > John Preuß Mattsson > > *From: *David Benjamin <[email protected]> > *Date: *Tuesday, 7 July 2026 at 18:36 > *To: *Mark Tehrani <[email protected]> > *Cc: *[email protected] <[email protected]> > *Subject: *[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends > 2026-07-08) > > 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]
