Hi Guilin,
On 7/11/26 14:33, Wang Guilin wrote:
Interesting topic!
As for a bad NRG, just taking m=NRG () could help attackers. Also,
if m is a good randomness, hashing or not hashing does not matter.
Yes, I think that is the core issue.
If the RNG is good, hashing `m` should not matter much beyond cost and
the exact proof model. If the RNG is bad in a structured way, especially
Dual_EC_DRBG-shaped, hashing `m` before encryption can matter a lot.
So, is it poissble that hashing, m'=H(m) or H(m||nonce), will bring
some new attacks or weaknesses that not applicable to no hashing,
m=NRG()?
By assuming that H is secure, it seems possible to prove that
hashing is more secure or at least secure as not hashing, at the
cost of running H and lost of some entropy in m.
That is roughly also my intuition. With proper domain separation, I
would expect `m' = H(label || m || context)` to be at least as
conservative for this specific issue, because it destroys hidden RNG
structure before the PKE encryption step. But, again, the issue is that
we want to destroy hidden structure - so first hash as Kyber did and at
least you'll have the Dual_EC_DRBG hidden structure destroyed in `m`.
You'll still need to systematically eliminate other protocol fields that
could serve as a similar passive covert channel directly on the wire or
reachable through some active channel.
There is also an interesting comparison with the Chinese schemes. If you
are implementing or reviewing Aigis-enc, LAC.PKE, and S-Cloud+, my
understanding from reviewing some different implementations and design
documents is that Aigis-enc inherited the Kyber-style hash over its
respective `m`, while LAC.PKE and S-Cloud+ did not. That gives us a
useful natural experiment: three related design choices, with different
answers to this exact question, can be compared over time.
So I agree with your framing: the question should be whether hashing
`m` introduces a real weakness when we know doing nothing leaves a
different real weakness that is exactly exploitable by large-scale
adversaries. If not, then for defense-in-depth against structured RNG
failures, hashing looks like the safer default.
I suspect your IPR concerns are also different than most other vendors.
Probably many people here would be interested to learn more about your
TLS libraries and your RNG designs.
Kind regards,
Jacob
Guilin
发件人：Jacob Appelbaum
<[email protected]<mailto:[email protected]>> 收件人：David Cooper
<[email protected]<mailto:[email protected]>>;[email protected]
<[email protected]<mailto:[email protected]>> 时 间：2026-07-11 05:23:17 主 题：
[TLS] Re: Generation of 'm' in ML-KEM (was Re: Re: [EXTERNAL] Re:
Re: [EXTERNAL] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends
2026-07-08))
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<http://
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]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
