> > but there's another patent holder, Yunlei Zhao, who wrote in
> > https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/m/F63mixuWBAAJ that "Kyber is covered by our patents". I haven't heard reports of Zhao > asking for money yet, but I also haven't seen a patent analysis > explaining why Zhao is wrong. Immediately after that message Yunlei declares "we hold all the patents only for protection against credit (not for economic reasons) <https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/m/fmBsJhLUBAAJ>" and "we can make such an official claims about patents [allowing anybody using it free use of our intellectual property, on condition that holders of other patents involved in this standard will allow free use of theirs] <https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/m/2NzgqoTaBAAJ> " On Thu, Oct 9, 2025 at 12:03 PM D. J. Bernstein <[email protected]> wrote: > It's good from a security perspective to see the increasing deployment > of post-quantum cryptography. The most widely deployed option in this > draft, namely X25519MLKEM768, is reportedly supported by ~40% of clients > and ~30% of the top 100K servers, so presumably it covers ~10% of TLS > traffic already, which is a big step above 0%. > > Regarding the choice of ML-KEM, the _hope_ that ML-KEM will protect > against quantum attacks shouldn't blind us to the _risk_ of ML-KEM being > breakable. Many other post-quantum proposals have been publicly broken > (see https://cr.yp.to/papers.html#qrcsp for a survey), including various > proposals from experienced teams. Kyber/ML-KEM itself has seen quite a > few vulnerabilities over the past 24 months, such as the following: > > * KyberSlash1 and KyberSlash2 (see https://kyberslash.cr.yp.to) > prompted two rounds of security patches to the majority of ML-KEM > implementations, including the reference code. > > * https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU > prompted another round of ML-KEM security patches. > > * https://eprint.iacr.org/2024/080 showed that NIST's claims of many > bits of extra ML-KEM security from memory-access costs---see > > https://web.archive.org/web/20231219201240/https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/faq/Kyber-512-FAQ.pdf > ---are, asymptotically, completely wrong for 3-dimensional attack > hardware and almost completely wrong for 2-dimensional attack > hardware. > > * https://eprint.iacr.org/2024/739 showed that the same claims from > NIST are, on real hardware, almost completely wrong. NIST has not > withdrawn the claims but also has not disputed these papers. > > * https://link.springer.com/chapter/10.1007/978-3-032-01855-7_15 > debunked previous claims that "dual attacks" don't work, and > concluded that none of the ML-KEM parameter sets reach their > claimed security levels. A Kyber team member has disputed this > conclusion, writing "there remains a few bits to be gained by > cryptanalysts before the security levels would be convincingly > crossed", but in any case this falls far short of the security > margin that NIST was claiming just two years ago. > > So it's good to see that the draft also meets the crucial requirement of > having an ECC layer in every option. An ECC layer means that moving from > today's X25519 (>80% of TLS) to X25519MLKEM768 definitely won't reduce > security, even if ML-KEM collapses: i.e., we can comfortably _try_ to > protect against quantum computers without risking a loss of security. > > However, the following two concerns are serious enough that I can't > support this draft in its current state. > > First concern: The other two options in the draft make unnecessarily > risky ECC choices, originally proposed by NSA in the 1990s. We've seen > many ECC failures since then because of implementation screwups, and > it's well understood (see https://cr.yp.to/papers.html#safecurves) how > better ECC choices reduce these risks. For example, instead of using > (x,y)-coordinates in ECDH and begging the implementor to check input > validity (something we've seen going wrong again and again), we should > be using x-coordinates on a twist-secure curve. > > I understand that there are some earlier standards requiring risky ECC > choices. I haven't seen a coherent argument that copying this flaw will > noticeably improve deployability of the draft. Meanwhile this flaw is > contrary to the "improve security" goal in the WG charter. > > A sub-concern here is that, since MLKEM1024 is somewhat less risky than > MLKEM768, it's reasonable for implementors to support MLKEM1024, but > then the draft forces those implementors to use a poor ECC choice. This > sub-concern is very easy to fix: add X25519MLKEM1024 and X448MLKEM1024. > > Kicking the can down the road, saying that these options can be added by > another spec later, would not address this sub-concern. An implementor > looking for the lowest-risk post-quantum option in _this_ spec is forced > into a poor ECC choice; _this_ spec should fix that. > > Second concern: Kyber has always been in the middle of a patent > minefield. The revisions to Kyber didn't do anything to move out of the > minefield. ML-KEM, which is Kyber version 4, is in the same minefield. > NIST claims that its license agreements with two patent holders (Ding > and GAM) allow free usage of unmodified ML-KEM under those patents; but > there's another patent holder, Yunlei Zhao, who wrote in > > > https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/m/F63mixuWBAAJ > > that "Kyber is covered by our patents". I haven't heard reports of Zhao > asking for money yet, but I also haven't seen a patent analysis > explaining why Zhao is wrong. > > What happens if a patent holder in, say, 2027 starts writing to one > company after another saying "Here are records showing you've used > ML-KEM, now pay $50000"? Probably a typical company pays the $50000 and > promptly disables ML-KEM, regressing to the undesirable situation of > users _definitely_ being unprotected against quantum attacks. Getting a > patent-free replacement to the same level of deployment will take years. > > The only way to provide interoperable post-quantum cryptography in this > scenario is for a patent-free post-quantum option to be implemented and > allowed everywhere, even if the patented option is default. Every spec > should be taking responsibility for providing patent-free options. As > above, kicking the can down the road does not address the problem; it > means that the necessary job doesn't get done. > > I'm not saying the WG should be trying to do patent analyses---on the > contrary, IETF has a rule saying that it won't decide validity of any > particular patent. I'm saying that the _claims_ from patent holders > regarding ML-KEM warrant adding more options to mitigate patent risks. > > ---D. J. Bernstein > > > ===== NOTICES REGARDING IETF ===== > > It has come to my attention that IETF LLC believes that anyone filing a > comment, objection, or appeal is engaging in a copyright giveaway by > default, for example allowing IETF LLC to feed that material into AI > systems for manipulation. Specifically, IETF LLC views any such material > as a "Contribution", and believes that WG chairs, IESG, and other IETF > LLC agents are free to modify the material "unless explicitly disallowed > in the notices contained in a Contribution (in the form specified by the > Legend Instructions)". I am hereby explicitly disallowing such > modifications. Regarding "form", my understanding is that "Legend > Instructions" currently refers to the portion of > > > https://web.archive.org/web/20250306221446/https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf > > saying that the situation that "the Contributor does not wish to allow > modifications nor to allow publication as an RFC" must be expressed in > the following form: "This document may not be modified, and derivative > works of it may not be created, and it may not be published except as an > Internet-Draft". That expression hereby applies to this message. > > I'm fine with redistribution of copies of this message. There are no > confidentiality restrictions on this message. The issue here is with > modifications, not with dissemination. > > For other people concerned about what IETF LLC is doing: Feel free to > copy these notices into your own messages. If you're preparing text for > an IETF standard, it's legitimate for IETF LLC to insist on being > allowed to modify the text; but if you're just filing comments then > there's no reason for this. > > _______________________________________________ > 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]
