I’d like to put on record my 100% agreement with Daniel Apon’s points.
-- V/R, Uri From: Daniel Apon <[email protected]> Date: Sunday, April 5, 2026 at 20:17 To: Peter Gutmann <[email protected]> Cc: [email protected] <[email protected]> Subject: [EXT] [TLS] Re: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem" This Message Is From an External Sender This message came from outside the Laboratory. Hi Peter, I remember, and enjoyed, your talk slides about an abacus and a dog. Scribble is adorable. It was not, as you claim for whatever reason, a breakthrough in that paper to provide a ZKP for their claim of a smaller reversible ECC-addition circuit; such techniques have been proposed many times before. (I don't particularly think it was especially useful to provide a ZKP attesting to knowledge of a smaller reversible ECC-addition circuit, but oh well. One can go verify the semantics of their NP language, their ZKP software, and their ZK proof, etc., if you like.) Also, I suppose "the middle distance" is Google's 2029 deadline now. Let me turn to a more important point (or, points) by Usama in this thread: "IMHO, unless some technical rationale is provided by IEEE 802.11, this LS should just be read as 'someone somewhere in the world would like to use pure ML-KEM' and TLS WG should not serve as a printing press for such requests." I completely disagree with the characterization that 'someone somewhere in the world would like to use pure ML-KEM.' It's dismissive of the current situation. Not only has the international community, after more than a decade of work, aligned on ML-KEM as the PQ-KEM standard, but IEEE (as a computer scientist, IEEE is not no one!) is requesting that the TLS WG "please stop delaying." Even further up the thread, Usama writes: "I was actually hoping to see some technical rationale for support of publication." May I please point you to https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf <72400682-baaf-4ea3-9f7a-42ad8b99b89f> or https://csrc.nist.gov/Projects/post-quantum-cryptography/email-list <0e13dc6f-55b0-4d6c-bdd0-d5bcaa953f60> for overwhelmingly sufficient technical rationale? If the international consensus on ML-KEM as the post-quantum KEM standard is insufficient, would you please explain further what you explicitly desire in terms of technical rationale? Kind regards, --Daniel On Sun, Apr 5, 2026 at 10:24 AM Peter Gutmann <[email protected] <f0b7ecbc-5feb-4c94-a883-31ee1eb5fd0c>> wrote: Viktor Dukhovni <[email protected] <593ad9d6-2a0b-42a2-92c7-02e3023a8793>> writes: >Recent theoretical progress on reducing the resource requirements (logical >qbits, and circuit sizes, i.e. gate counts and time) for breaking 256-bit ECC >with Shor's algorithm, may have reduced the perceived value of the ECC >components of hybrids for some QC "optimists" who were betting on CRQC's to >show up in O(decade), but now think it may much sooner than previously >expected. It's yet another paper, following 25 years of well-established precedent, that begins with the authors gazing into the middle distance and saying "assuming we have a functioning magic device" and then constructing some elaborate framework based on this imaginary device. Except that in this case they're not even telling us what the framework for the imaginary device is. There's a page or two of vague generalising about what they can do towards the start, and the remainder of the 57-page paper is telling us how terrible things will be if the magic works. We can't even get someone to perform the same astounding feat of mathematics as a barking dog or an abacus yet because no-one knows what's been discovered. The real breakthrough in the paper seems to be the elaborate means they've come up with to hide what they've actually done. So I'm not losing any sleep over it. Peter. _______________________________________________ TLS mailing list -- [email protected] <67174b66-c159-4110-82f2-9d1ee370f51c> To unsubscribe send an email to [email protected] <00478633-1b85-464d-a75d-7cf5d3228de9>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
