[TLS] Re: [EXT] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3

[Jacob Appelbaum <[e-mail]>]

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
> <[e-mail]> 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 <[e-mail]> 
>>>> 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 <[e-mail] 
>>>> <mailto:[e-mail]>> 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 -- [e-mail] To unsubscribe send an email to tls-
>>>> [e-mail]
>>> 
>>> 
>>> _______________________________________________ TLS mailing list
>>> -- [e-mail] To unsubscribe send an email to tls-
>>> [e-mail]
>> 
>> _______________________________________________ TLS mailing list
>> -- [e-mail] To unsubscribe send an email to [e-mail]
>> 
>