Hi Jacob, If you're going to allege a grand conspiracy, it's important to get the basic facts correct, or you'll lose the plot. :)
You wrote: " - NIST cryptographers are required to carry a clearance with lifetime obligations and to consult with NSA in a way that binds them to secrecy under threat of serious penalty" This is simply false. Moreover, the NIST PQC team was composed of many guest foreign researchers, who participated in every part of the process including the decision meetings, to which it would be a crime to divulge classified information. If you're going to double down, you'll perhaps need to indict various European governments too! And while I have zero obligations that prevent me from open dialogue on anything related to this, I'm not interested in engaging in a speculative, often fanciful, politically-tinged discussion that *something evil somewhere has **happened*, especially when it's based on interpretations that seem plainly misinformed. (In good faith, I assume you were simply misinformed, rather than speaking with malice aforethought.) I am, however, interested in discussing the scientific and technical merits of the WCLC of this draft, if there are any substantive concerns. If you're able to write a fresh email highlighting the technical matter that you're interested in (separated from whatever you'd call the rest of that, so that I don't have to try to pick out this or that and guess at what technical matter is actually interesting to you), I'd be happy to discuss further. Kind regards, --Daniel On Thu, Apr 23, 2026 at 7:48 AM Jacob Appelbaum <[email protected]> wrote: > Hi Daniel, > > On 4/23/26 04:34, Daniel Apon wrote: > > Hi Jacob, > > > > You wrote: " A non-exhaustive list of ways that one might avoid pure > > PQ: - if the PQ crypto fails as SIKE failed - if some or all of > > Peter Gutmann's criticisms about CRQCs are correct - if the PQ > > crypto fails in a novel way that CRQCs enable - if the it is > > impractical to break both ECC and the PQ during the window in which > > it matters - if the PQ crypto deployment gives adversaries an > > opportunity to sabotage previously functional cryptography and thus > > break security - recommendations and/or regulations that impose a > > hybrid requirement" > > > > > > Please allow me to address each (trying to delineate where > > reasonable points of disagreement exist versus points that don't, to > > me, seem reasonable): > > > > Are you able to share your threat model and ideally any obligations that > hinder open dialog? > > Allow me to go first with a rough threat model: I am concerned about > well funded Large Scale Adversaries engaged in strategic and tactical > sabotage. Active attacks on the internet including pervasive mass > surveillance, and active attacks on TLS. These concerns are contextually > relevant to this list. > > I am not bound by any NDA in this field, nor have I ever applied for, or > held, a US (or other) government clearance. I have no legal lifetime > obligations to silence, and indeed my obligations are almost the > opposite: I have worked with confidential sources to publish information > that is in the public interest. > > > > > " - if the PQ crypto fails as SIKE failed" > > > > This is a common public misunderstanding of the NIST PQC process. > > No, I do not think so. I do not believe that I misunderstand the NIST > PQC process. I see it from the outside while I understand you may see it > from the inside, as your own work, at least in part. I may be wrong, and > I welcome learning more about your experience and context. I am not > disparaging your efforts either as much as I am expressing a lack of > confidence in my own government's processes and long term strategies. > > That is to say, I am perhaps disparaging aspects of NIST's result. I > filed official comments[0] with NIST as part of that process which show > that the PQC process resulted in changes that myself and others find > problematic. Those comments were not addressed formally by > cryptographers at NIST or the relevant political leadership. > > I have directly spoken to various sources at NIST (and NSA) who have > told me that they are not entirely free to speak on these matters. This > does not surprise any of the usual knowledgeable people who understand > how the sausage is made. Surprise or not, it lowers confidence in the > NIST PQC process and in NIST as well. > > Academic cryptographers are as impressive as they are underfunded and > under resourced. This is not to disparage the efforts by those academic > cryptographers working in the open. Respectfully, their expertise is > immense. Unfortunately, even their expertise and especially their > resources are completely dwarfed by the Large Scale Adversaries playing > the field. > > > One should not view SIKE as being broken as a knock against greater- > > than-decade-long PQC standardization processes, but rather a wildly > > successful outcome of such processes and a testament to the > > mathematical rigor applied to PQC standardization that SIKE *was not > > standardized* while waiting for an attack to be published. Full > > stop. > > > > Unfortunately, this is misunderstands points made about SIKE by a > country mile and it reflects at least a difference of perception if not > experience. It probably reflects a difference of knowledge as well but I > will try not to presume to know what you know. > > This is part of the context: > - NIST is required by law to consult with NSA[1] > - Neither NIST nor NSA has adequately addressed the cryptographic > sabotage shown in PROJECT BULLRUN[2] and specifically Dual_EC_DRBG[4] to > ensure there can never be a repetition > - The IETF and specifically TLS was targeted[3] as part of this sabotage > - No one has been held accountable for decades of cryptographic sabotage > - People involved with cryptographic sabotage wittingly, and even > unwittingly, continue to be involved with cryptographic systems and also > with standardization > - NIST cryptographers are required to carry a clearance with lifetime > obligations and to consult with NSA in a way that binds them to secrecy > under threat of serious penalty > - NSA cryptographers are also required to carry a clearance with > lifetime obligations > - Those cryptographers are generally not supposed to talk about their > lifetime obligation but some of them do, thankfully > - Some of those lifetime obligated cryptographers switch to industry > which in turn ties back to PROJECT BULLRUN's tactics and strategies > which include infiltration of standards bodies, companies, and software > projects. The shoulder tap combined a request is a valid attack that is > extremely challenging to counter > > > This leads us back to SIKE: > - Many Cryptographers expressed confidence in SIKE that was unfounded > - SIKE being broken shows the brilliance of a handful of people while > also highlighting the limits of open cryptanalysis > - SIKE being broken *and published* by someone other than NIST when NIST > is required by law to consult with NSA is expected with what we know > about PROJECT BULLRUN > - It is fairly implausible that NSA did not know before the public, > especially given the targeted NSA (and other agencies) surveillance of > cryptographers and their respective workplaces, including in Europe > - The fact that open cryptanalysis broke something that was in round > four is being used to glaze the overall process itself which is > undeserved. That research came from the academic community and the > context merely provided incentives. Unfortunately, it also provides a > locus of control such as with patents and regulatory levers > - The NIST process provides pressure to switch from something we > understand to be secure today to something we hope will be secure > tomorrow while also giving a lever for change control to NIST (and by > extension of US law, NSA). That lever was used, and it is still being used > > Harm reduction is one lesson: Deployments of PQ crypto that were later > broken remain secure today because of hybrid constructions as part of > those PQ experiments. We probably can't resolve all of the issues above > but we can avoid making risky choices that benefit Large Scale Adversaries. > > " - if some or all of Peter Gutmann's criticisms about CRQCs are > > correct" > > > > Without diving down into rabbit holes about dogs and waffles or > > whatever other satire, was there a serious technical point worth > > highlighting? Historically, one of the best "cartoon form" arguments > > in Garey and Johnson's book "Computers and Intractability: A Guide > > to the Theory of NP-Completeness" was on page 3, captioned: *"I > > can't find an efficient algorithm, but neither can all these famous > > people."* > > > > To wit: in this situation, we have many famous people working on > > building CRQCs. Some have recently won the Nobel Prize in Physics > > for their work towards large-scale quantum computing engineering. To > > be clear, the majority corpus of expert opinion is clearly in favor > > of a near-to-medium-term CRQC emerging. > > > > Nevertheless, if one switches to PQ without hybrid constructions today, > one may not need a quantum computer. > > A quantum computer may or may not arrive, but the fatal mistake of > removing a known good thing in exchange for a new speculative thing is > poor risk management. It seems reasonable to consider quantum computers > as an engineering problem just as cryptographic sabotage is an > engineering problem. We should seek systematic, safe choices that center > on protecting (internet) user first. Corporations and governments have > weighed in along with other technically skilled folks, and their > interests differ from the regular user in many cases. Those regular > users are people who will be stuck with the defaults. They will often > not even know that they're making a tradeoff that isn't even mentioned > in the security considerations of an internet standards document. > > > > > " - if the PQ crypto fails in a novel way that CRQCs enable" > > > > There seems to be no such potential pathways that are believable/ > > known, despite various attempts in the past years by Yilei Chen and > > Yifan Zhang. > > > > I recall in round three[5] of the NIST process that you were quoted as > saying: “SIKE is a fantastic scheme, but its computation is by far the > most expensive, and the problem is relatively new. Who knows here?” > > To echo your previous curiosity while not endorsing things where I lack > confidence in the scheme, I would ask the same question: Who knows here? > > There is evidence in the literate says that new attacks against PQ > systems will continue to improve using regular computers and that the > security boundaries of some PQ cryptography when faced with an existing > quantum computer may be lower than initially estimated. There are > credible disputes about the NIST calculations of PQ security levels. > > > > > " - if the it is impractical to break both ECC and the PQ during the > > window in which it matters" > > > > This is somewhat of a more valid point, and it comes down to a > > question of the intelligence lifespan of data. In some scenarios, > > maybe an hour or a day is the relevant information content of data. > > In others, years or decades are not enough to erase the sensitivity > > of communications. > > This is a strange thing to say in the context of signatures. We probably > agree about the risks of decryption of data purloined through targeted > and mass surveillance. If so, I am glad that we can find a common point > of agreement. However, it seems to be a category error to discuss the > concerns of implied decryption of mass surveillance data, say stored at > the Bluffdale MDR, when signature forgery is the topic of discussion. > > A conservative hybrid signature construction should protect against > signature forgery including any failures in the new PQ system. Long-term > security starts with being secure today, and optimizing away the > security we rely on today is reducing the total number of hard problems > underlying the security assumptions of these cryptographic systems. > > > > > Certainly, hybrid ECC+PQC (in whatever form it occurs) may be more > > reasonable for relatively less sensitive data, but for more > > sensitive data, the "window in which it matters" is inherently long. > > > > And in the longer window, fewer hard problems is... better? If the keys > are otherwise unrelated and securely combined, I would enjoy reading > your reasoning. If the concern is that it won't be done correctly, well, > yes, that is indeed a problem. Thankfully we have some things already > that appear to be as good as it gets; we should not throw them away. > > > > > " - if the PQ crypto deployment gives adversaries an opportunity to > > sabotage previously functional cryptography and thus break security" > > > > I suppose that's why the world participated in a decade-long common > > evaluation process to vet the new cryptography, which was not only > > standardized without serious technical objection to the security of > > the PQ cryptographies, but was standardized with alternative > > technical opinions left objectively wanting in public. It took many > > years for the global conversation to reach that final point. > > Without NIST systematically addressing comments and concerns that were > filed as part of that process, you're ironically reinforcing my > observation. > > If you're saying the math is fine, we're probably talking past each > other. Yes, many cryptographers think that the math is fine or that they > don't see a problem which isn't quite the same result as thinking it to > be fine. > > Meanwhile, I have spoken with (American, European, and other) > cryptographers who simply refused to engage with the NIST process at all > for a variety of reasons. This may be a blind spot for a former NIST > person but I suspect you're well aware. Though there are cryptographers > who don't think all of the math is fine, and others still report that > they don't always understand the math. The latter two are especially > concerning and seem to be implicitly dismissed by your line of reasoning. > > The changes imposed by NIST (and by extension influenced by NSA as > required by US law) aren't all mathematically interesting. I noted some > of this in my comments to NIST. There is much to say on this topic. Most > of all it is worth noting that there is published evidence of NSA and > related agencies targeting TLS, IPsec, SSH, and other widely deployed > cryptographic systems. NSA sabotaged standards, software, and even > hardware all the same. The hardware sabotage includes but is not limited > to SIGINT enabling of CPUs produced by an American (fabless > semiconductor) firm[6]. The NSA and related Large Scale Adversaries have > many confirmed successes in breaking the security of the systems. The > NSA influence over on NIST over many decades imposes a serious burden on > NIST's credibility, as do the security clearance lifetime obligations of > people who know more than they are allowed to say in the open. Large > Scale Adversary interference includes social, political, workplace, and > even technical ostracism[7] as part of the documented playbook. > > > > > " - recommendations and/or regulations that impose a hybrid > > requirement" > > > > This is a great reason to want an option for hybrid PQC+ECC, but > > it's not a reason to forbid pure PQC. Businesses (such as mine) that > > participate as vendors in multiple markets will spend the > > appropriate effort to satisfy local regulations in each > > jurisdiction, of course. > > > > Defaults matter and upcoming standards will be seen as de facto > transition documents that endorse specific kinds of deployments. This > document endorses a more risky deployment than is reasonable for those > with concerns about Large Scale Adversary interference in cryptographic > security. I remain open to the possibility that there are compelling > arguments while still remaining opposed to publication at this time even > after considering your points. > > Kind regards, > Jacob Appelbaum > > [0] > > https://csrc.nist.gov/files/pubs/fips/203/ipd/docs/fips-203-initial-public-comments-2023.pdf > [1] https://www.lawfaremedia.org/article/nsas-subversion-nists-algorithm > [2] > > https://www.propublica.org/article/the-nsas-secret-campaign-to-crack-undermine-internet-encryption > [3] > > https://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html > [4] https://projectbullrun.org/dual-ec/ > [5] > > https://csrc.nist.gov/CSRC/media/Events/third-pqc-standardization-conference/documents/accepted-papers/costello-case-for-sike-pqc2021.pdf > [6] > > https://www.computerweekly.com/news/366552520/New-revelations-from-the-Snowden-archive-surface > [7] https://cryptome.org/2014/02/gchq-online-deception.pdf and > > https://www.aclu.org/sites/default/files/assets/the_art_of_deception_training_for_online_covert_operations_0.pdf > (see page 48 for an instant classic) > > > > > On Wed, Apr 22, 2026 at 5:49 PM Jacob Appelbaum > > <[email protected]> wrote: > > > >> Hello Uri, > >> > >> On 4/22/26 21:52, Blumenthal, Uri - 0553 - MITLL wrote: > >>> There can be arguments about the life expectancy of hybrids - > >>> from zero to CRQC appearance - but can be no objection to the > >>> point that once CRQC is here, only pure PQ will make sense. > >>> > >> > >> With respect, I suspect that there there will be measurements > >> rather than mere speculative arguments. > >> > >> The life expectancy will depend greatly on such a machine > >> existing, who has such a machine, who is willing to reveal that > >> they have such a machine, how efficient and/or useful it is for > >> practical attacks, and most importantly if the PQ cryptography > >> actually survives contact with that reality. The latter point > >> seems particularly challenging as a discussion point. > >> > >> Something that I haven't seen raised in this discussion is a > >> possible middle ground where we see something like the proposed > >> TWINKLE[0]/TWIRL[1] machines where breaking a single key may be > >> feasible but cost prohibitive at scale. Those proposed systems did > >> not force RSA into retirement. Meanwhile, LOGJAM[2] resulted in > >> RFC8270 rather than RSA's end. > >> > >> There are several kinds of PQ failures that we have seen, > >> additional failures that we expect to see, and a few that many of > >> us hope won't happen at all. SIKE remains a humbling example that > >> is seemingly avoided in many of these discussions. > >> > >>> Thus, arguing against pure PQ makes no sense in my opinion: you > >>> may be able to delay long enough to avoid hybrids, but there’s > >>> no way you’d avoid pure PQ. — Regards, Uri > >> > >> As of today, there isn't a quantum computer that is public and > >> breaking ECC. We are fairly confident that ECC is secure today > >> modulo various kinds of NOBUS and other kinds of cryptographic > >> sabotage. We are also fairly confident that ECC will fall > >> eventually if there is a quantum computer. Most people are > >> confident that there will be a relevant quantum computer and that > >> we should prepare. It seems odd to prepare by increasing the risk > >> of attacks by computers that already exist today. > >> > >> A non-exhaustive list of ways that one might avoid pure PQ: - if > >> the PQ crypto fails as SIKE failed - if some or all of Peter > >> Gutmann's criticisms about CRQCs are correct - if the PQ crypto > >> fails in a novel way that CRQCs enable - if the it is impractical > >> to break both ECC and the PQ during the window in which it matters > >> - if the PQ crypto deployment gives adversaries an opportunity to > >> sabotage previously functional cryptography and thus break > >> security - recommendations and/or regulations that impose a hybrid > >> requirement > >> > >> Hybrid compositions make sense for encryption and for signatures. > >> Attacks with a quantum computer to break the cryptographic > >> encryption or signature system(s) may be roughly the same but I am > >> not convinced that the consequences are equal. It is remarkable > >> that signature forgery isn't considered more of a concern than > >> HNDL. > >> > >> Arguing for a belt rather than suspenders and a belt is often a > >> reasonable fashion choice but is it an equally secure and > >> resilient system? > >> > >> Kind regards, Jacob Appelbaum > >> > >> [0] https://en.wikipedia.org/wiki/TWINKLE [1] https:// > >> en.wikipedia.org/wiki/TWIRL [2] https://en.wikipedia.org/wiki/ > >> Logjam_(computer_security) > >> > >>>> On Apr 22, 2026, at 13:25, Nicola Tuveri <[email protected]> > >>>> wrote: > >>>> > >>>> Hi Rich, thanks for your clarification, indeed my phrasing > >>>> was not ideal. I’ll take your comment as a chance to clarify > >>>> my stance. Code point assignment and deployment support are > >>>> distinct considerations. In practice, non-experimental > >>>> production ZjQcmQRYFpfptBannerStart This Message Is From an > >>>> External Sender This message came from outside the Laboratory. > >>>> ZjQcmQRYFpfptBannerEnd > >>>> > >>>> Hi Rich, > >>>> > >>>> thanks for your clarification, indeed my phrasing was not > >>>> ideal. I’ll take your comment as a chance to clarify my > >>>> stance. > >>>> > >>>> > >>>> Code point assignment and deployment support are distinct > >>>> considerations. In practice, non-experimental production > >>>> deployments generally rely on both assigned code points and a > >>>> published standard. > >>>> > >>>> > >>>> Concerns about the proliferation of standards introducing > >>>> support for additional code points are not uncommon on this > >>>> list. I note a similar concern here in support of delaying > >>>> this draft. > >>>> > >>>> > >>>> At present, the process risks creating the impression of a > >>>> “first- to-standard” outcome, where publication effectively > >>>> determines the direction of deployment before the trade-offs > >>>> have been fully examined, possibly even stalling the progress > >>>> of other drafts. In particular, the argument that introducing > >>>> additional options increases complexity has been raised > >>>> repeatedly on this list, but it does not seem sufficient on > >>>> its own to guide decisions in a security area WG. It would be > >>>> preferable to more explicitly evaluate the security properties > >>>> of hybrid and non-hybrid approaches and reach a position that > >>>> can inform what should-and should not-be advanced to standard. > >>>> > >>>> > >>>> Best regards, > >>>> > >>>> Nicola Tuveri > >>>> > >>>> > >>>> > >>>> On Wed, Apr 22, 2026 at 19.30 Salz, Rich <[email protected] > >>>> <mailto:[email protected]>> wrote: > >>>> > >>>> * I have read the draft, but I do not support its publication > >>>> at the moment. > >>>> > >>>> > >>>> * My rationale is that this draft adds complexity by adding > >>>> extra code points for pure mldsa. > >>>> > >>>> > >>>> Code points are assigned when a stable reference is available, > >>>> as you might recall from the long threads on the pure ML-KEM > >>>> draft. So I don’t think your stated rationale makes sense. > >>>> > >>>> _______________________________________________ TLS mailing > >>>> list -- [email protected] To unsubscribe send an email to tls- > >>>> [email protected] > >>> > >>> > >>> _______________________________________________ TLS mailing list > >>> -- [email protected] To unsubscribe send an email to tls- > >>> [email protected] > >> > >> _______________________________________________ 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]
