Thanks, Sean! On Tue, Apr 28, 2026 at 3:16 PM Sean Turner <[email protected]> wrote:
> These last two messages are veering off-topic for this WGLC thread, as > well as for the TLS WG list. You are, obviously, free to continue this > discussion privately. > > spt > > > On Apr 28, 2026, at 12:23, Jacob Appelbaum <[email protected]> wrote: > > > > Hi Daniel, > > > > On 4/27/26 15:32, Daniel Apon wrote: > > > >> 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. :) > > > > > > I am not alleging a grand conspiracy. I cited public records, internal > > documents, press reporting, and standards history in [0], [1], [2], [3], > > [4], [5], [6], and [7]. Those materials are part of a historical record, > > not speculation. PROJECT BULLRUN, targeting of TLS, and Dual_EC_DRBG are > > part of that context [2][3][4]. My involvement in that history was as an > > investigative journalist and security researcher. Our work followed the > > plot(s) fairly well and if you have comments to the contrary, please be > > specific and say so directly. > > > > A grand conspiracy could probably be a fair characterization of what was > > uncovered in the Summer of Snowden. It was refreshing to read that > > framing from a former NIST/MITRE person, until I understood you to mean > > that I was the one making the allegation. > > > > Please note, however, that those allegations were backed by former US > > IC personnel and contractors who came forward with documents, testimony, > > or both. There has still been essentially no meaningful transparency or > accountability for most of those programs, especially PROJECT BULLRUN and > specifically the Dual_EC debacle. > > > >> 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. > > > > > > Which part exactly is false? > > > > The sentence you quoted was also not a free-standing accusation. It was > > part of a longer point about why SIKE being broken should not be treated > > as a vindication of the NIST process. SIKE not being standardized was a > > good outcome. It does not follow that NIST deserves most of the credit, > > or that a process which advanced SIKE deep into consideration should be > > treated as fully reassuring. > > > > On the clearance point, the category matters. I was referring to NIST > > cryptographers in a NIST/NSA consultation context, not every intern, > > foreign guest researcher, non-US citizen, or temporary affiliate working > > on an unclassified topic. A clearance is not a read-in to every > > classified program. > > > > Sometimes NIST makes the clearance issue explicit. In [8], when NIST was > > openly advancing key escrow, NIST wrote: > > > >> Access to classified information is anticipated, and a current U.S. > government secret clearance is required for participation in this program. > The first phase of the research program is expected to last two to three > years. > > > > > > That is relevant history and a valid example. The 2010 NIST/NSA MOU in > > [9] says it replaces, supersedes, and extends a 1989 NIST/NSA agreement. > > It also created a Technical Working Group with three NIST and three NSA > > US federal employees. Item five required that group to review matters > > before public disclosure for consistency with the national security of > > the United States, and item six allowed additional operational > > agreements in annexes [9]. > > > > That is a structural transparency problem. Unless you were part of that > > TWG or a later NIST/NSA arrangement, I would not expect you to know the > > details of those discussions or annexes. If you were part of such a > > process, item five suggests public disclosure would be constrained by > > national-security review [9]. > > > > US citizenship also appears to be a common requirement in NIST > > cryptography research opportunities [10][11][12][13]. Citizenship is not > > a clearance, and a clearance is not a read-in. But when NSA briefs a > > NIST cryptographer through classified NIST/NSA channels, that person > > must be authorized to receive the information, and unauthorized > > disclosure of classified cryptographic or communications-intelligence > > information can carry serious penalties under 18 U.S.C. 798 [15] as > > well as other laws. > > > > NIST itself acknowledges limits on transparency in NIST/NSA > > collaboration. NISTIR 7977 says [14] the following: > > > >> The names of some NSA staff cannot, by law, be publicly revealed. 50 > U.S.C. 402 note. Freedom of Information Act (FOIA) requests for documents > involving any NIST-NSA collaboration are normally reviewed by both > organizations and exempted or excluded information, which may include the > names of specific NSA participants as noted, may be redacted. > > > > > > Is that fact in dispute? It is odd to characterize this as a grand > > conspiracy claim when much of what I am quoting was published by NIST. > > > >> 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. > > > > > > You appear to be making a category error by shifting from NIST > > cryptographers to the NIST PQC team. My statement was specifically > > scoped to the former, and your shift to the latter is a > > misunderstanding of the scope. > > > > NIST cryptographers who are US federal employees could be eligible to > > participate in a NIST/NSA TWG; foreign guest researchers on the NIST > > PQC team could not receive classified information merely by > > participating in the PQC team. > > > > It may be unlawful for cleared NIST cryptographers with access to a > > relevant classified program to disclose classified information outside > > authorized channels to people not authorized to receive it. That > observation supports, at most, that classified information was not lawfully > disclosed in the NIST PQC team meetings. > > > > It does not show that NIST cryptographers lacked clearances, that > > NIST/NSA consultation occurred only in those meetings, or that cleared > > NIST personnel would be free to disclose classified information learned > > elsewhere. Can you point readers to a full accounting of those meetings? > > > >> If you're going to double down, you'll perhaps need to indict > >> various European governments too! > > > > > > No double down is needed. My previous message already cited documents > > showing international collaboration. Did you mean that you did not read > > those documents, that you dispute them, or that I misunderstood your > > point? > > > >> And while I have zero obligations that prevent me from open dialogue on > anything related to this, > > > > > > My preemptive disclosure was that I have no such obligations of any > > kind: I do not hold, and have never held, a clearance. > > > > Your statement is notable for what it does not say. You did not say that > > you have never held a clearance, never filled out an SF-86, never signed > > an SF-312, never participated in a classified NIST/NSA channel, or never > > had obligations on adjacent matters. You said only that you have zero > > obligations preventing open dialogue on anything related to this. > > > > Maybe that is fully reassuring. Maybe it is a lawyerly non-denial. I am > > not asking you to disclose protected information. I am pointing out that > > this ambiguity is itself a structural problem. A public reader cannot > > verify whether anything related to this includes all relevant facts, or > > only the subset that you are allowed to discuss. > > > >> 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.) > > > > > > Nor am I. Please stop misrepresenting what I have written. Please engage > > with the cited material, or state which parts you dispute. I am > > interested in the specific facts at issue. You did not refute or even > > address the cited points. You characterized accurate historical facts, > > and the resulting standards-process concerns as an allegation of a grand > > conspiracy. > > > > The technical point remains simple: SIKE shows that serious, multi-year > > review can miss major failures until late. That argues for deployment > > conservatism. If a new post-quantum component fails, a safely composed > > hybrid can leave a classical component protecting users. A stand-alone > > post-quantum construction removes that margin. > > > > > >> 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. > > > > > > Most of the core concerns remain including but not limited to: > > > > - Stand-alone post-quantum signatures remove a hard problem that > > protects users today, while adding a newer assumption that may fail > > either as a mathematical matter or as an implementation matter. > > > > - Signature forgery is not the same risk as harvest-now-decrypt-later. > > > > - Defaults matter. Publishing stand-alone ML-DSA code points in TLS can > > function as a de facto transition signal. > > > > - A standards process with classified NIST/NSA channels and a documented > > history of cryptographic sabotage needs explicit safeguards, not > > assurances amounting to "trust us", especially after trust in that > > process was seriously damaged by NIST and NSA with regard to Dual_EC. > > > > Three additional process questions follow: > > > > - How can a technical standardization process at IETF defend against > > well funded sabotage such as PROJECT BULLRUN, including similar > > efforts by other adversaries? > > > > - What should IETF do with technical suggestions from people related to > > organizations that have sabotaged security, including in IETF > > standards? > > > > - What can you share about what NIST did during the PQC process to > > address these concerns, given that NIST did not publish the SIKE break > > and given that NIST did not mandate hybrids? > > > > 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) > > > > [8] > https://web.archive.org/web/20260427204037/https://www.nist.gov/news-events/news/1994/02/nist-calls-partners-developing-key-escrowing-hardware > > > > [9] > https://web.archive.org/web/20260427204720/https://csrc.nist.gov/csrc/media/projects/crypto-standards-development-process/documents/nist_nsa_mou-2010.pdf > > > > [10] > https://web.archive.org/web/20260427211339/https://ofell.nas.edu/RAPLab10/opportunity/opportunity.aspx?LabCode=50&RONum=B7613&ROPCD=507731 > > > > [11] > https://web.archive.org/web/20260427215706/https://ofell.nas.edu/RAPLab10/opportunity/opportunity.aspx?LabCode=50&ROPCD=507711&RONum=C1031 > > > > [12] > https://web.archive.org/web/20260427215649/https://ofell.nas.edu/RAPLab10/opportunity/opportunity.aspx?LabCode=50&ROPCD=507731&RONum=C0556 > > > > [13] > https://web.archive.org/web/20260427215624/https://ofell.nas.edu/RAPLab10/opportunity/opportunity.aspx?LabCode=50&ROPCD=507731&RONum=B7615 > > > > [14] > https://web.archive.org/web/20260427224507/https://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.7977.pdf > > > > [15] https://www.law.cornell.edu/uscode/text/18/798 > > > > > >> 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 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]
