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]
