Hi Quynh,
Thanks for replying.
On 7/9/26 16:15, Dang, Quynh H. (Fed) wrote:
Everything I wrote in the message at 9:44AM US Eastern time 7/8/2026
is factual regardless of many questions you had for me about things.
That statement appears to include your earlier claim:
"The group authoring FIPS 203 did not have any meeting with the NSA and
the NSA had zero authorship of the FIPS 203."
That remains unreconciled with the public record unless you are using
very narrow definitions of "group authoring FIPS 203," "meeting," and
"authorship." Public FOIA material says there was substantial NSA
involvement in NIST PQC work, including secret NSA/NIST PQC meetings and
NSA participation in the [email protected] team [2]. It also includes an
email saying comments from "Donna and the NSA" were incorporated into
the PQC NISTIR, and that PQC NISTIR is cited by FIPS 203 [3][4].
If your point is only that NSA was not listed as an author of the final
FIPS 203 document, please make that clear to readers here. That is a
much narrower claim than saying that the group authoring FIPS 203 had no
meeting with NSA or that NSA had zero authorship or influence relevant
to FIPS 203.
The public record released by NIST after being subject to a lawsuit
appears to contradict those broader claims: it shows NSA involvement in
NIST PQC work, an email saying comments from "Donna and the NSA" were
incorporated into the PQC NISTIR, and that NISTIR is cited by FIPS 203.
Every technical change was publicly discussed at the pqc-forum and
there was a publicly known reason for the change.
That public discussion is not the same as analysis of this TLS failure
mode even though some points touched on the Dual_EC_DRBG concern.
You wrote [0] on behalf of NIST in May 2023:
"We appreciate the discussion about Kyber's tweaked FO transform. While
there are arguments that can be made for either including or not
including the hash of m during Encaps, NIST is not planning to include
this step in the upcoming draft standard for Kyber."
You then wrote:
"The upcoming standard focuses on FIPS-certifiable implementations,
which includes auxiliary functions such as the RGB. In the case of a
standardized version of Kyber being deployed in a non-FIPS-certified
setting, it is possible than an attacker can back-door the RBG to learn
all future outputs. In this case, NIST believes that adding an extra
hash to Kyber will not do much to mitigate the potential harms faced by
the jeopardized system."
That is not a technical analysis of the TLS case. It is an assertion
that NIST "believes" the hash will not do much good because the rest of
the system may already be jeopardized.
The primary public reasons against hashing can be summarized as: hashing
`m` has implementation cost, side-channel concerns were raised,
environmental cost was raised, and FIPS 203 requires an approved RBG
[0][1][4]. None of that answers the specific TLS question: if a TLS
server samples `m` directly from a Dual_EC_DRBG-shaped RBG, does the
decapsulating client get an RNG-state-recovery oracle that Kyber's
original `m <- H(m)` step would close?
Beside the removal of the hash of m, are there any other technical
details concerning you about the security of ML-KEM in TLS 1.3 ?
Yes. The removal of the hash over `m` is the primary technical concern.
The IPR/licensing question is the second technical concern because it
affects whether implementers are free to deploy the obvious mitigation.
For clarity, please answer these as technical yes/no questions:
1. Does FIPS 203 `ML-KEM.Encaps()` [4] sample a fresh 32-byte `m` and
pass it to `ML-KEM.Encaps_internal()` without Kyber's original `m <-
H(m)` step?
2. In TLS 1.3 standalone ML-KEM, does the client send an ML-KEM public
key and does the server encapsulate to it, producing a ciphertext that
the client decapsulates [5]?
3. Can a client that controls its own ML-KEM implementation instrument
decapsulation and recover the server's internal `m` value?
4. If that `m` is raw output from a Dual_EC_DRBG-shaped RBG, and the
client has the corresponding Dual_EC_DRBG secret/trapdoor, can that `m`
serve as an RNG-state-recovery sample?
5. Would restoring Kyber's `m <- H(m)` step before encapsulation destroy
the Dual_EC_DRBG algebraic structure available to that decapsulating peer?
6. Does the current TLS draft's Security Considerations clearly state
the FIPS 203 approved-RBG dependency and explain the security
consequence of removing Kyber's hash over `m`?
7. Do NIST's patent license agreements cover implementations that
restore Kyber's `m <- H(m)` step before `ML-KEM.Encaps_internal()`?
8. Do NIST's patent license agreements cover implementations that derive
`m` from an approved or non-approved RBG through a hash/XOF construction
before encapsulation?
9. If the answer to 7 or 8 is no, is NIST willing to say publicly that
it will seek clarification, amendment, or an additional license so
implementers can deploy this mitigation without IPR uncertainty?
If the answers to 1-6 are yes, yes, yes, yes, yes, and no, then the TLS
draft has a concrete Security Considerations defect. The WG does not
need to re-litigate all of NIST PQC to fix that. It can simply say: hash
`m`, or at minimum state the FIPS 203 approved-RBG assumption and the
risk of raw RNG-derived `m`.
If the answers to 7-9 are unclear, then the patent situation is not a
side issue. It is a technical deployment blocker. The obvious mitigation
is to restore the Kyber hash over `m`, but implementers need to know
whether NIST's patent license agreements cover that mitigation or only
ML-KEM exactly as published by NIST.
If the latter is the case then the Security Considerations of the draft
should at a minimum mention the _requirement_ from FIPS 203 that ML-KEM
requires a NIST-approved randomness source, and ideally it should also
state that not hashing `m` was based on the security assumption of that
requirement. Do you disagree with either of those two technical points?
PS: Don't be surprised if I don't answer your questions if I think
they are not technically important to ML-KEM's security in TLS 1.3.
These questions are exactly about ML-KEM's security in TLS 1.3 and about
whether implementers are legally free from NIST's perspective to deploy
a technical mitigation.
In any case, I am not surprised but I would like to be! Please do
consider answering the questions posed in a systematic way even if that
isn't the normal NIST process.
Kind regards,
Jacob Appelbaum
P.S.
People reading the FOIA release [3] probably fairly wonder: What,
exactly, did Donna and the NSA [3] have to say that was folded into the
later cited PQC NISTIR?
[0] https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/
m/o2XJ2YvfAwAJ
[1] https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/
m/d8SFB2RhAAAJ
[2] https://nist.pqcrypto.org/foia/highlights.html
[3] https://nist.pqcrypto.org/foia/20230508/PQC%20NISTIR%20version%202.pdf
[4] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
[5] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
-----Original Message----- From: Jacob Appelbaum
<[email protected]> Sent: Wednesday, July 8, 2026 2:11 PM To:
Dang, Quynh H. (Fed) <[email protected]>; TLS List
<[email protected]> Cc: Markku-Juhani O. Saarinen
<[email protected]> Subject: Re: [EXTERNAL] Re: [TLS] Re:
[EXTERNAL] Re: WG Last Call: draft-ietf- tls-mlkem-08 (Ends
2026-07-08)
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.or/
g%2F10.6028%2FNIST.IR.8413-
upd1&data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed945f404f1
a1b08dedd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%
7C639191384484652031%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc
GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld
UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3Rlb5zid5iEipm%2F2fzO%2FMsL
GO8tIfr2nPEBwbPA6u4I%3D&reserved=0 "
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.p/
qcrypto.org%2Ffoia%2Findex.html&data=05%7C02%7Cquynh.dang%40nist.
gov%7C8a0445ed945f404f1a1b08dedd2d61b4%7C2ab5d82fd8fa4797a93e
054655c61dec%7C0%7C0%7C639191384484715842%7CUnknown%7CTW
FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa
W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KQ
D%2F%2FTl4lLVgd1YCz5WHMVboj9k7mBmT8iAR8Ypwd%2FQ%3D&reserved =0
[1] https://nist.p/
qcrypto.org%2Ffoia%2Fhighlights.html&data=05%7C02%7Cquynh.dang%40
nist.gov%7C8a0445ed945f404f1a1b08dedd2d61b4%7C2ab5d82fd8fa4797
a93e054655c61dec%7C0%7C0%7C639191384484767533%7CUnknown%7
CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi
JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=l
7f7UaDwXTyaTXOuYwYqn2YceWpcuAxic42VhpgiATE%3D&reserved=0
[2] https://nist.p/
qcrypto.org%2Ffoia%2F20230815%2FRe_%2520pqc%2520mailing%2520list
&data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed945f404f1a1b0
8dedd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C63
9191384484812340%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO
nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy
fQ%3D%3D%7C0%7C%7C%7C&sdata=esh2gmMa5l0D9chFkhE%2FgusyQP0
9wP0ndToGTyUj4bA%3D&reserved=0(1)-3.pdf
[3] https://web/.
archive.org%2Fweb%2F20230910091944%2Fhttps%3A%2F%2Fcsrc.nist.gov
%2FCSRC%2Fmedia%2FEvents%2FISPAB-MARCH-2014-
MEETING%2Fdocuments%2Fa_quantum_world_v1_ispab_march_2014.pdf&
data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed945f404f1a1b08d
edd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C6391
91384484853183%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
%3D%3D%7C0%7C%7C%7C&sdata=7fBkCMQjFUXEEl5M07iBe8Ahnf0gm%2
BHps5sQ9KRXb2Q%3D&reserved=0 was authored by "Post Quantum
Cryptography Team, National Institute of Standards and Technology
(NIST), [email protected]"
[4] https://nist.p/
qcrypto.org%2Ffoia%2F20230815%2FRe_%2520pqc%2520mailing%2520list
&data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed945f404f1a1b0
8dedd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C63
9191384484884591%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO
nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy
fQ%3D%3D%7C0%7C%7C%7C&sdata=7qLvBB0Se4BCW5rT2D6Qe4%2FW66
LwDds5xMDEFF5iNz8%3D&reserved=0(1)-3.pdf includes the list of
[email protected] people
[5] https://nist.p/
qcrypto.org%2Ffoia%2F20230915%2FRe_%2520PQC%2520NISTIR%2520ve
rsion%25202&data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed94
5f404f1a1b08dedd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0
%7C0%7C639191384484909081%7CUnknown%7CTWFpbGZsb3d8eyJFbXB
0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp
bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sdhN0Wr05ckhl9vb4Roy
qPnTC86VVzZWkEwAW55GlcY%3D&reserved=0(2).pdf
[6] https://nvlpu/
bs.nist.gov%2Fnistpubs%2FFIPS%2FNIST.FIPS.203.pdf&data=05%7C02%7Cq
uynh.dang%40nist.gov%7C8a0445ed945f404f1a1b08dedd2d61b4%7C2ab
5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C639191384484927281%
7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu
MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C
%7C%7C&sdata=6IyafioHpbMx620xq1tn0MgWzftZUcipmB5Zx2qS3Bk%3D&r
eserved=0
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
http://www/.
etsi.org%2F&data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed945f
404f1a
1b08dedd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7
C639191384
484950857%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs
IlYiOiIwLjA
uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7
C%7C%7
C&sdata=EhOquPsB1E2uZKRWUnBDEZ3K0dxtG8Gg3smMDcFxIa4%3D&reser
ved=0%2Fd
eliver%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]
