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]
