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