Hello David,
On 7/10/26 18:52, David Cooper wrote:
This will be my only email on this subject, as it is completely off-
topic for this mail list.
It is not off-topic. The topic is the security of ML-KEM, which is the
draft under discussion. The sub-topic is "Generation of `m` in ML-KEM."
The consensus period has ended, but there still seems to be confusion
about key aspects of ML-KEM, and also about the claim that everything
relevant was settled in the NIST process. It is fairly clear that there
are matters relevant to TLS that are not settled in favor of protecting
users.
I appreciate that NIST is continuing to engage with the discussion. The
full-court press from NIST is positive, even when it seems incoherent;
our tax dollars are being well spent.
I assume your email here is not an official NIST statement, but that you
are speaking from your experience as a NIST person.
I also have no interest in responding to a potentially endless
stream of questions.
I will keep this mostly to facts for the readers at home. They can make
up their own minds. Naturally, NIST answering direct questions would
make everything go much faster. Even faster would be proactive
disclosure without anyone needing to ask. I will take what I can get.
When I look at https://nist.pqcrypto.org/foia/index.html, I only
see a small number of emails sent to [email protected],
Please note that NIST could have proactively published all of this and
saved us the trouble of wondering if there is still more to be revealed.
and all of them are from 2016 or 2017.
That may be true for the subset of visible emails sent to
`[email protected]`, but it does not show that NSA involvement stopped in
2017. The same FOIA release includes June 2020 internal material with
NSA-originated technical comments on the Round 2 report [0].
Let us examine the editorial track-changes record from a June 2020 NIST
document produced in the lawsuit. With apologies to Dustin Moody of
NIST, it is important to mention him to present an accurate
understanding. The Morgan mentioned here is understood to be Morgan
Stern from NSA, the same Morgan Stern subscribed to and posting on this
list. I could be mistaken about that, and hopefully Morgan will
participate in the discussion. As the joke goes, if you want to talk to
NSA, pick up the phone and call your mother. Here I will just post on
the list and hope that the calls to my mother do not bring NSA to the
discussion.
For example, there is a track-changes comment by Dustin Moody on June
16, 2020 on page 5 that says:
"from Morgan: Do you have a strong preference for timing versus power?
Also, are you calling for more analysis of implementations (many
algorithms have implementations, not many have independent
verification of claims)?"
On page 8:
"from Morgan:
You may want a summary of lattice-based and a summary of code-based
(or a glossary) as certain terms are just repeatedly mentioned which
may not make so much sense out of context (Regev's LWE, CoreSieve,
information set decoding, Fujisaki-Okamoto)."
"Dustin: I don't want a glossary, but curious what others think."
"from Morgan: I will just point out here that prior to your
competition this was not a well-known transform, so it probably bears
citing somewhere (and maybe saying in the summary how much work has
occurred tightening the reductions in the quantum case)."
"from Morgan: I've always felt very odd about this line of work: On
the nonce-reuse work (as opposed to the other fault papers) the attack
works because the author went with an easy-to-implement strategy. If
they had done something less elegant (which would have been criticized
for being sloppy and would be more prone to mis-implementation) there
still could have been an attack, but it would have been less likely to
be found."
"Doesn't appear to suggest a change - rather just an observation"
That Dustin was reading for suggestions to change the report sure
appears like Dustin was editing for Morgan. Why deny NSA involvement or
influence when these documents show NIST people taking technical and
editorial suggestions from NSA?
On page 9:
"from Morgan: First mention of this so you likely want a citation. If
you decide to have a lattice overview, you may also want to mention
why you are using this metric (call out the "Estimate all the {LWE,
NTRU} schemes" paper you had at your first conference, or Darmstadt
Lattice Challenge record recently).
Also, you are inconsistent with the capitalization of the phrase."
"from Morgan: I might comment on the fact that they themselves went
into considerable analysis on what the precise strength was (as in, it
was what they aimed for)."
Dustin responds with:
"I added a citation. Is it the right one?"
The end of page 9 is interesting primarily because it contains
discussions about cryptanalytic attacks:
"In NIST's view, FrodoKEM may be suitable for use cases where a low
security risk from cryptanalytic attacks is considered much more
important than performance. NIST's first priority for standardization
is a KEM that would have acceptable performance in widely-used
applications overall. As such, possible standardization for FrodoKEM
can likely wait until after the third round. FrodoKEM could also serve
as a conservative backup, in the case of new cryptanalytic results
being discovered in the third round. For these reasons, FrodoKEM was
not selected as a finalist, but as one of the alternate candidates
advancing."
Page 9 includes Morgan highlighting this part of the above paragraph:
"low security risk from cryptanalytic attacks"
Morgan's comment says:
"from Morgan: I would likely not use this phrase"
Page 10 includes this:
"from Morgan: I would probably try for a "bottom-line" a little
earlier here. Start the paragraph with something like: In a technical
sense, the security is never better than Kyber."
This text ended up in NIST's official rationale for choosing Kyber rather
than NewHope.
There are other comments such as this gem on page 19:
"NIST encourages the DILITHIUM team to add a category 5 parameter set.
More study is also needed on understanding the concrete security, as
DILITHIUM has relatively lower CoreSVP security strength than other
lattice-based round 2 schemes. NIST selected DILITHIUM as a finalist,
and expects that either DILITHIUM or FALCON will be standardized as
the primary post-quantum signature scheme at the conclusion of the
third round."
The following text is highlighted:
"More study is also needed on understanding the concrete security, as
DILITHIUM has relatively lower CoreSVP security strength than other
lattice-based round 2 schemes."
The comment says:
"from Morgan: if you want them to up their CoreSVP, you should
explicitly say it, since you don't want them to change their
parameters partway through round 3."
Page 22 has the following text:
"NIST researchers noted a gap between performance and theoretical
complexity for a few attack avenues relevant to the Rainbow scheme.
During the second round, some tighter theoretical analyses of as well
as new algorithms for these well-known attacks have been published,
see [20] and [15]. In particular [20] shows that a parameter tweak is
necessary for all parameter sets to achieve the claimed levels of
security. Still, with a more conservative parameter selection it will
be possible to meet the claimed security levels with minimal
performance cost."
This sentence is highlighted from the paragraph above:
"In particular [20] shows that a parameter tweak is necessary for all
parameter sets to achieve the claimed levels of security. Still, with
a more conservative parameter selection it will be possible to meet
the claimed security levels with minimal performance cost."
This is the comment associated with the highlight:
"from Morgan: the Rainbow designers may not have much time to digest
your analysis, and I would assume you want to standardize whatever
parameters come into Round 3."
Dustin added a second comment directly after the above comment:
"He also noted that the write-up could be taken as a case for Rainbow
being an alternate, so the reasons for being a finalist should be
emphasized."
Page 23 highlights "SPHINCS+" in the Section 3.26 header:
"from Morgan: Your write-up for SPHINCS+ reads very similarly to the
write-up for McEliece but you conclude it is a backup for
standardization, as opposed to a standard that is ready to go as a
backup."
Personally, I would not characterize NSA as having no involvement or
influence when the released documents show that NSA clearly communicated
technical and editorial suggestions and evaluated evidence about
rankings. NSA thought NIST would not want Dilithium to change its
parameters partway through round 3. NSA also said there could be a case
for Rainbow being an alternate.
I am not even disagreeing with Morgan's observations. I am concerned
that NIST did not show this communication in public without being sued
by an interested third party to force production of the documents. I am
also baffled why NIST later obfuscates and plays word games where it
refused to engage with basic technical questions.
This behavior by NIST is not engendering trust. This is in the context
of trust in NIST being seriously damaged by public reporting about
PROJECT BULLRUN's cryptographic sabotage, including using NIST to push
Dual_EC_DRBG.
By the way, Morgan was probably correct in at least one way when he
commented: "In a technical sense, the security is never better than
Kyber" - after all, Kyber hashed `m` at that point in time.
I find it hard to believe that Morgan would say that Kyber-with-hashed-m
and ML-KEM-with-raw-m are the same.
The most interesting result I see when searching this page for
"[email protected]" is from May 2017:
We hope you'll be part of our post-quantum crypto project....
...
I've added you to the email alias "[email protected]" which we
use to send PQC stuff to all the other members of the project (all
NIST people).
Whereas the last email to "pqc" appears to have been sent before the
deadline for submitting proposals for PQC algorithms, many emails
were sent to "internal-pqc" over the years.
This website's contents are the result of an adversarial legal process
where NIST had to be sued to reveal the documents on that webpage. I was
not involved with the lawsuit. I find it hard to believe that it is a
comprehensive list of all NIST communications during the PQC process. We
actually know that it is not a comprehensive list. NIST should save
everyone the time and publish everything.
The email saying that comments from Donna and the NSA were
incorporated into the NISTIR was sent in January 2016. The comments
were on a NISTIR that Dustin said he hoped to publish by the end of
month if possible (end of January 2016). The NISTIR 8413 cited in
FIPS 203, which reports on the third round of the PQC
standardization process, was published in 2022. According to
https:// csrc.nist.gov/Projects/post-quantum- cryptography/
publications, NISTIR 8105, Report on Post-Quantum Cryptography, was
published in April 2016. Perhaps Donna and the NSA commented on
NISTIR 8105.
The "perhaps" is doing a lot of work in that sentence. It would be
better if NIST just told us without a lawsuit.
Regardless, NISTIR 8105 [1] also does not mention that NSA gave comments
and that its feedback was incorporated. NISTIR 8413 following it is
naturally related, and the public messaging from NIST about NSA's
involvement remains lacking. It also strains credibility when absolute
claims by NIST are contradicted by NIST's own documents, but only after
a lawsuit produces them.
It seems that an actual reading of the FOIA material presents a very
different picture than the message below.
Sure, if you selectively read what interests you, and if you are not
part of the NIST/NSA working group, I would expect a selection bias that
would bias the view of the overall situation as well.
You are welcome to clarify your own role in the NIST/NSA working group
if you think that would help readers understand the situation. Various
security clearance obligations and other conflicts of interests are
helpful context for everyone.
Totally unrelated, but contrary to the impression given in my emails, I
actually like many NIST standards. Especially NIST's synthetic turf
on-site laboratory assessment accreditation [2].
I also like my coffee like I like my cryptographic standards: strong and
without any secret NSA influence.
Thank you for your work on ML-KEM. I hope you will encourage hashing of
`m` and that NIST will issue errata for defense-in-depth against
Dual_EC_DRBG-shaped threats.
All the best,
Jacob Appelbaum
[0] https://nist.pqcrypto.org/foia/20241115/
pqc%20round%202%20report.pdf-attachment-
PQC%20Report%20on%20Round%202%20June%2016.docx
[1] https://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8105.pdf
[2] https://www.nist.gov/system/files/documents/2020/11/12/
LB-133-2020%20Synthetic%20Turf%20Testing%20in%20CCC.pdf
On 7/8/26 11:10, Jacob Appelbaum wrote:
Hello Quynh,
Thank you for your reply.
On 7/8/26 15:43, Dang, Quynh H. (Fed) wrote:
Hi Jacob,
The group authoring FIPS 203 did not have any meeting with the
NSA and the NSA had zero authorship of the FIPS 203.
This is a surprising statement given the public information about
NIST and NSA's relationship.
Public FOIA material [0] appears to show substantial NSA
involvement in NIST PQC work, which makes your statement
surprising and worth clarifying.
The FOIA highlights [1] say the [email protected] team included more
NSA members than NIST members and that NSA had secret input/
meetings with NIST on PQC, but that is broader than FIPS 203
authorship:
"NIST's Post Quantum Cryptography Team was mostly NSA. The FOIA
results show that what NIST publicly labeled as the "Post Quantum
Cryptography Team, National Institute of Standards and Technology
(NIST), [email protected]" actually had more NSA members than NIST
members. The secret NSA members of the [email protected] team were
Bradley C. Lackey, Daniel Kirkwood, David Hubbard, David Tuller,
Jerry Solinas, John McVey, Laurie Law, Mark Motley, Nick
Gajcowski, Scott Simon, and later Rich Davis." [2] [3] [4]
Some of those names are familiar to me. Are any on this list
taking a position on the draft in question? A wonderful moment
for government transparency has presented itself. Thank you to
the IETF for this opportunity.
Looking at the released documents such as [5] where a well-known
NIST (Top) Cryptographer wrote in his email: "I’ve incorporated
the revisions and edits we discussed regarding the comments
received from Donna and the NSA." Quynh - the email metadata from
that FOIA release says that you were in the CC list.
How should the public reconcile your claim with the released
email [5] saying that comments from "Donna and the NSA" were
incorporated?
Is this a mistake or a misunderstanding? For example are you not
counting [5] comments from the NSA... because their feedback was
incorporated into the PQC NISTIR version 2 document as part of the
larger PQC process? Does that mean NIST's position is that FIPS
203 wasn't influenced by their own PQC NISTIR document? I read
`NISTIR` in Section 2.2 Acronyms (on page 4) of FIPS 203 and the
NISTIR is cited as reference [23] (on page 43) of FIPS 203 [6]:
"Alagic G, Apon D, Cooper D, Dang Q, Dang T, Kelsey J, Lichtinger
J, Liu YK, Miller C, Moody D, Peralta R, Perlner R, Robinson A,
Smith- Tone D (2022) Status report on the third round of the NIST
post- quantum cryptography standardization process (National
Institute of Standards and Technology, Gaithersburg, MD), NIST
Interagency or Internal Report (IR) 8413. https://
doi.org/10.6028/ NIST.IR.8413-upd1 "
I do not see how to reconcile your statement with the public FOIA
record without a more precise definition of "the group authoring
FIPS 203," "meeting," and "authorship."
It would be immensely helpful if you or NIST could clarify - who
do you include by name in the group authoring FIPS 203 and what
exactly do you mean by a meeting?
It sounds pedantic, I realize. Unfortunately it is only because
of a proactive lawsuit against NIST that members of the public
are able to cite the above emails. NIST could do themselves a big
favor here and release significantly more information without
being forced through legal process.
At the time of authoring/writing FIPS 203, we were very
confident in the security of the NIST-approved RBGs, we wanted
people to use them, so the FIPS had a requirement of using an
appropriate security strength NIST-approved RBG.
Didn't NIST write FIPS 203 _after_ NIST's John Kelsey did the
retrospective on NIST's failure in the Dual_EC_DRBG fiasco? Was
this history not part of your threat model or included in your
(internal or external) analysis in any documented manner?
There's an old joke about the TSA and how it tries to solve
yesterday's security threats tomorrow. Is NIST... at least trying
to solve its own security catastrophes of a decade ago... today
or at least for... tomorrow?
As others have pointed out before, hashing m in the ML-KEM's
spec only protects the KEM, the whole system is still considered
compromised when other crypto functions rely on the security of
the broken or attacker-controlled RBG.
Okay - I understand that we agree that hashing `m` is not harmful
to the ML-KEM spec. I also understand that we agree that hashing
m even protects the KEM.
But do I understand the rest of your point? I read you as saying
that... NIST... left the `m` unhashed so that the KEM would be
unprotected because... the rest of the system would also be
compromised anyway?
Do you dispute that, if `m` is produced by a Dual_EC_DRBG-shaped
RNG, not hashing `m` allows a TLS client to obtain a useful
oracle that hashing `m` would close?
Hashing `m` would protect the KEM and close this ML-KEM oracle
against a Dual_EC_DRBG-shaped NOBUS advantage for a large-scale
adversary. Naturally, if the larger protocol leaks a similar RNG
state before or after, we would have more than one problem to
resolve. Still, we should try to resolve each of the issues
rather than pointing at related problems to justify solving none
of them.
We think we made a good judgement call to remove the hash
(discussed in my previous email). We also understood the
reason that some others wanted to keep the hash.
What is the standard of evidence that would convince you
personally or NIST to the contrary to issue an errata such that
`m` is hashed to prevent this issue?
For example, what if someone showed you a construction to make
ML- KEM not just secure against this exact issue but also to
resolve the hybrid debate without any extra bytes on the wire? I
have such a design and I have implemented it.
Relatedly, would NIST ensure that the patent/IPR concerns would
not be enforced against such an implementation?
It would help to clarify whether NIST’s patent license agreements
apply only to ML-KEM as published by NIST, or also to variants
that hash `m` or otherwise transform `m`. If developers are free
to hash `m` or to use a non-NIST-approved RBG under NIST's patent
license agreements, I am certainly not alone in welcoming
clarification on this matter.
I have posed many questions, and I appreciate you taking the time
to read them. Thanks in advance, and thank you again for your work
authoring FIPS 203.
Kind regards, Jacob Appelbaum
[0] https://nist.pqcrypto.org/foia/index.html
[1] https://nist.pqcrypto.org/foia/highlights.html
[2] https://nist.pqcrypto.org/foia/20230815/
Re_%20pqc%20mailing%20list(1)-3.pdf
[3] https://web.archive.org/web/20230910091944/https://
csrc.nist.gov/ CSRC/media/Events/ISPAB-MARCH-2014-MEETING/
documents/ a_quantum_world_v1_ispab_march_2014.pdf was authored
by "Post Quantum Cryptography Team, National Institute of
Standards and Technology (NIST), [email protected]"
[4] https://nist.pqcrypto.org/foia/20230815/
Re_%20pqc%20mailing%20list(1)-3.pdf includes the list of
[email protected] people
[5] https://nist.pqcrypto.org/foia/20230915/
Re_%20PQC%20NISTIR%20version%202(2).pdf
[6] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
Regards, Quynh.
-----Original Message----- From: Jacob Appelbaum
<[email protected]> Sent: Wednesday, July 8, 2026 7:21 AM
To: Dang, Quynh H. (Fed) <[email protected]>; TLS List
<[email protected]> Cc: Markku-Juhani O. Saarinen
<[email protected]> Subject: [EXTERNAL] Re: [TLS] Re:
[EXTERNAL] Re: WG Last Call: draft-ietf-tls- mlkem-08 (Ends
2026-07-08)
Hi Quynh,
On 7/8/26 12:57, Dang, Quynh H. (Fed) wrote:
And NSA did not ask us to consider removing the hash.
For transparency and clarity: Are you making this statement
as a participant in the confidential NIST/NSA working group
meetings as part of authoring FIPS 203?
Kind regards, Jacob Appelbaum
Regards, Quynh.
From: Dang, Quynh H. (Fed) Sent: Wednesday, July 8, 2026
6:42 AM To: TLS List <[email protected]> Cc: Markku-Juhani O.
Saarinen <[email protected]> Subject: RE: [EXTERNAL]
[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends
2026-07-08)
Hi all,
See the discussion here about removing the hash of the
message m.
https://gcc02.safelinks.protection.outlook.com/?
url=https%3A%2F%2Fgrou
ps.google.com%2Fa%2Flist.nist.gov%2Fg%2Fpqc-
forum%2Fc%2FWFRDl8DqYQ4%2F
m%2FqmVANi7EAwAJ&data=05%7C02%7Cquynh.dang%40nist.gov%7C27e
432e9a9ac41
68aad008dedce325b9%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C
0%7C639191
065341348557%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
WUsIlYiOiIwL
jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0
%7C%7C%
7C&sdata=nrQbwjt%2FNOMJAsb43n8djjf6m1ec%2BeAkEKUJSq1gIXQ%3D&
reserved=0
The reason to remove it was that hashing m would be bad,
introduce a cost
for side-channel security implementations (ask Markku for
detail). In addition, we require an approved RBG. If the RBG
of a system is broken, or controlled by the attacker, the
security of the whole system should be assumed to be broken
anyway.
I was a main author of the FIPS 203.
Top level cryptographers know ML-KEM was not back-doored.
Regards, Quynh.
From: Thom Wiggers
<[email protected]<mailto:[email protected]>>
Sent: Wednesday, July 8, 2026 5:52 AM To: Eliot Lear
<[email protected]<mailto:[email protected]>> Cc:
<[email protected]<mailto:[email protected]>>
<[email protected]<mailto:[email protected]>> Subject: [EXTERNAL]
[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends
2026-07-08)
Hi,
ML-KEM is arguably not backdoorable unless you break the
RNG. Bad RNG is
something that we can't really protect against anyway. Classic
cryptography is also broken if the RNG is busted. Finally, the
TLS key schedule still mixes in all messages from both sides
rendering the point moot for TLS.
On a more instructive point, ETSI's "quantum-safe enterprise
transport
security" (ETSI TS 104 145<https://
gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2F
www.etsi.org%2Fdeliver%2Fetsi_ts%2F104100_104199%2F104145%2F01.0
1.01_60%2Fts_104145v010101p.pdf&data=05%7C02%7Cquynh.dang%40n
ist.gov%7C27e432e9a9ac4168aad008dedce325b9%7C2ab5d82fd8fa4797a
93e054655c61dec%7C0%7C0%7C639191065341386930%7CUnknown%7C
TWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ
XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=g
gAnSn%2FHdBJ81j13mWw9Z%2FVAH47LG8xEjoNjarVQE0g%3D&reserved=0
, paragraph 5.3.2) relies exactly on generating the
encapsulation seed
deterministically instead of randomly sampling one. This
mainly breaks forward secrecy, which is certainly bad. But
hybrids or not are not relevant to this. In the classic
approach they simply fixed the DH public key of the server,
iirc. Friends don't let friends use ETS.
Cheers,
Thom
Op 8 jul 2026, om 11:35 heeft Eliot Lear
<[email protected]<mailto:[email protected]>>
het volgende geschreven:
Hi!
~~~~Disclaimer I'm not a cryptographer. ~~~~
Please see below. On 08.07.2026 08:04, Viktor Dukhovni
wrote:
On Tue, Jul 07, 2026 at 10:27:56PM -0700, Christian Huitema
wrote:
I just read Jacob Applebaum's message. Given his
description of the
late-standardization suspicious change that looks like a
backdoor in the
ML-KEM specification, I agree with his conclusion. The WG
should not ask for
publication of the current graph, not until the changes
requested by Jacob
are made.
The removal of whitening of the `m` random input to Encaps
is not a
plausible backdoor. If all you have is a broken RNG, you're
free to
apply whitening to obtain a new less bad RNG and use that
instead.
Nothing stops an ML-KEM implementation from hashing some
input (any
number of times, mixing in whatever additional inputs, ...)
to produce
its random values. The abstract algorithm starts from the
final output
of an adequate RNG that requires no further post-processing.
There's nothing suspicious about this simplification. The
critique in
question makes no sense to me. Don't use a broken RNG.
That sounds about right to me, but as someone who is not a
cryptographer,
perhaps someone who is could explain how this amounts to a
back door, and not a requirement for a good PRNG? And if
it's not a back door, should we really relitigate NIST's
choices here?
Eliot
* By "back door", I mean an intentionally placed undisclosed
weakness that
could be exploited by the people who placed it there.
<OpenPGP_0x87B66B46D9D27A33.asc>_______________________________
_______
_________ TLS mailing list --
[email protected]<mailto:[email protected]> To unsubscribe send an
email to [email protected]<mailto: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]
