Hi Simon and David,
On 7/12/26 17:24, Simon Josefsson wrote:
David Stainton <[email protected]> writes:
Restoring the hash is reasonable and NIST's removal wasn't well
motivated or justified, their silence to reasonable questions now
is suspicious when we consider the relevant history.
There may be better designs but they will only slow down
deployment. The best course of action is restoring the hash over
m. It lasted for three rounds without a security issue being found
by NIST or NSA.
I am going to update the golang hpqc library and the katzenpost
mixnet project will take the defense in depth route.
The NIST Kyber patent license only grants you a license to use ML-
KEM when implemented according to NIST specifications.
Yes. FIPS 203 also requires fresh random bytes for ML-KEM.KeyGen and
ML-KEM.Encaps to be generated using an approved RBG, as prescribed in
SP 800-90A/B/C. FIPS 203 further says the Kyber `m <- H(m)` step was
removed because NIST requires approved randomness generation.
That combination creates a practical problem: implementers who restore
Kyber's original defense-in-depth hash, or otherwise derive `m` before
encapsulation, may worry that they are no longer implementing ML-KEM "as
published by NIST."
This is exactly why NIST should clarify whether restoring `m <- H(m)`,
or otherwise deriving `m` for defense-in-depth, remains covered by the
relevant patent arrangements and conformance expectations.
If you deviate, such as by taking the defense-in-depth approach to
hash m to improve robustness against a compromised PRNG, the NIST
patent license does not cover your usage.
That may be the result, or it may not be. I am not giving legal advice.
The problem is that the license and conformance situation appears
unclear, and that uncertainty itself discourages safer implementations.
This is exactly why projects such as hpqc need clarification: if their
ML-KEM implementation is not exactly the NIST-published algorithm, or if
their randomness source is not an approved RBG, the license and
conformance situation may be unclear.
People in the IETF used to prefer patent un-encumbered technology,
but things are different today.
My understanding is also that the draft does not take a position on the
IPR issue. That is unfortunate, because the IPR issue and the security
issue interact here.
In the context of TLS, removing the hash can turn ML-KEM.Encaps into an
oracle on the sender's RNG output in the Dual_EC_DRBG-shaped case. I
have implemented a TLS-oriented demonstration of that RNG-state recovery
mechanism. This is not a claim about breaking all TLS deployments; it is
a demonstration of why handing raw RNG-derived `m` to the decapsulating
peer is a bad protocol habit.
https://csrc.nist.gov/csrc/media/Projects/post-quantum-
cryptography/ documents/selected-algos-2022/nist-pqc-license-
summary- and- excerpts.pdf
Different sabotage strategies for different concerns at different layers
is the repeated theme of large-scale adversaries.
The common wisdom is that (large-scale) Adversaries only need to win
once. Meanwhile defenders have to work uphill to convince other
defenders that there are Adversaries in the first place.
Wait until you hear about GCHQ's JTRIG [0] operations [1] [2]! By
comparison NIST's patent control strategy is relatively mild to JTRIG
[3]. NIST's patent and conformance posture may discourage implementers
from restoring Kyber's original defense-in-depth hash over `m`. Is it
intentional to guide people into this obviously beneficial direction?
Well, if we can't _know_, why don't we just make sure the answer is
irrelevent rather than risk it?
To me this means thta the TLS draft should either restore the hash, or
explicitly warn that ML-KEM `m` is recoverable by the decapsulating peer
and should not be drawn from the systems' raw primary RNG output.
John previously suggested that I was too focused on NSA and not enough
on European SIGINT agencies. Fair enough: GCHQ is also publicly
documented as a BULLRUN partner, and there is extensive reporting on
JTRIG, TEMPORA, and UK pressure around encryption [0]-[17]. I do not
need to re-litigate all of that here. The relevant lesson is simple:
large-scale adversaries influence, pressure, and exploit cryptographic
systems at many layers. They're not the only ones [13] that do this kind
of stuff, unfortunately. That is why the TLS draft should choose
defense-in-depth when the cost is essentially one hash.
NIST's own historical material is again relevant because it is simply
unbeleivable to most people. The Don Johnson (cygnacom) / John Kelsey
(NIST) email to Larry Basham on NIST's site is part of the public record
of how NSA influence complicated NIST's ability to explain Dual_EC_DRBG
[18]. All three of them knew in 2004 that NSA wasn't allowing this issue
to be discussed, and it still took almost a solid decade for the facts
to come out.
That history is exactly why clarity on `m`, IPR, and the approved-RBG
dependency matters now.
I really encourage you to read this very short document:
https://csrc.nist.gov/CSRC/media/Projects/Crypto-Standards-Development-Process/documents/Email_Oct%2027%202004%20Don%20Johnson%20to%20John%20Kelsey.pdf
Here's the important quote from Don at cygnacom, an NSA contractor, to
John at NIST:
"P=G.
Q is (in essence} the public key for some random private key.
It could also be generated like a(nother} canonical G, but NSA
kyboshed this idea, and I was not allowed to publicly discuss it,
just in case you may think of going there."
This email exchange was forwarded to Larry at NIST in _2004_. Good news
for people worried about entropy: Larry is and was listed as the person
responsible for the "NIST Statistical Test Suite reference
implementation" [19] at NIST ("Last updated: July 16, 2014"). It appears
that three people can keep a secret after all. The NSA is pretty
persusive. It's had to fault these three guys, and I don't personally.
The fault lies with NIST and NSA, and NSA has damaged the public trust
in NIST. The larger structural issue is that NSA should not be able to
put pressure on American scientists as they did in just thing single
example as this is at odds with the duty of scientists to be able to
find and to discuss the truth.
So when NIST isn't answering questions, we unfortunately have to accept
that there are plausibly at least two reasons: they're being
unreasonable and not engaging with fair questions or they're reasonably
not going to say something if NSA doesn't allow it.
Most journalists would really like to see any involved people follow
Edward Snowden's example but that's asking a lot of anyone. That's why
we should consider the (historical and contemporary) examples that we
have as sufficient evidence to take the conservative path and we should
not simply assume the fundemental underlying dynamics are different.
Kind regards,
Jacob Appelbaum
[0] https://web.archive.org/web/20190626033632/https://theintercept.com/
document/2014/02/24/art-deception-training-new-generation-online-covert-
operations/
[1] https://web.archive.org/web/20190528015932/https://
assets.documentcloud.org/documents/1021430/pages/the-art-of-deception-
training-for-a-new-p48-large.gif
[2] https://web.archive.org/web/20190528015930/https://
assets.documentcloud.org/documents/1021430/pages/the-art-of-deception-
training-for-a-new-p20-large.gif
[3] https://statewatch.org/wp-content/uploads/2026/04/gchq-jtrig-
interference.pdf
[4] https://theintercept.com/2015/06/22/controversial-gchq-unit-
domestic-law-enforcement-propaganda/
[5] https://christopher-parsons.com/resources/the-sigint-summaries/gchq-
covernames-programs-and-suggested-use-implementation/
[6] https://fahrplan.events.ccc.de/congress/2017/Fahrplan/events/9233.html
[7] https://s3.amazonaws.com/s3.documentcloud.org/documents/1217406/
jtrigall.pdf
[8] https://www.aclu.org/sites/default/files/assets/
gchq_cyber_attack_honey_trap_1.pdf
[9] https://www.aclu.org/documents/jtrig-tools-and-techniques
[10] https://original.antiwar.com/justin/2014/02/27/the-worst-snowden-
revelation-of-them-all/
[11] https://nsarchive.gwu.edu/document/22372-document-07-mandeep-k-
dhami-defence-science-and
[12] https://www.theguardian.com/science/2015/aug/16/britains-twitter-
troops-ways-making-you-think-joint-threat-research-intelligence-group
[13] https://www.spycops.co.uk/
[14] https://www.theguardian.com/uk/2013/jun/21/gchq-cables-secret-
world-communications-nsa
[15] https://www.amnesty.org.uk/knowledge-hub/all-resources/why-taking-
government-court-mass-spying-gchq-nsa-tempora-prism-edward-snowden/
[16] https://www.spiegel.de/netzwelt/web/edward-snowden-ueber-tempora-
macht-der-britischen-datensauger-a-909849.html
[17] https://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-
codes-security
[18] https://csrc.nist.gov/CSRC/media/Projects/Crypto-Standards-
Development-Process/documents/
Email_Oct%2027%202004%20Don%20Johnson%20to%20John%20Kelsey.pdf
[19]
/Simon
David Stainton Founder and core developer, Katzenpost post quantum
mixnet
On Sun, Jul 12, 2026 at 1:08 PM Kris Kwiatkowski
<[email protected]> wrote:
On 12/07/2026 09:06, John Mattsson wrote:
Regarding Jakob Appelbaum's suggested text, I agree that wording
along the lines of "the m value is recoverable by the
decapsulating peer" should be added to draft-ietf-tls-ecdhe-
mlkem, draft-ietf-tls-mlkem, and likely to future IETF KEM
specifications as well.
I agree with the points below, including that the broader CSPRNG
guidance discussion belongs in a wider IETF context such as an
RFC4086bis effort.
On where the suggested text about 'm' being recoverable by the
decapsulating peer should go: I think draft-sfluhrer-cfrg-ml-
kem- security-considerations is the proper home for it, rather
than the documents that merely define code points for TLS. The
TLS drafts could then simply reference it. Duplicating ML-KEM
security considerations across draft-ietf-tls-ecdhe-mlkem,
draft- ietf-tls-mlkem, and every future KEM code point document
seems fragile, and a single CFRG document keeps the guidance
consistent. This follows the same logic as your RFC4086bis
suggestion: put the guidance where it can be referenced, not in
each protocol-specific draft.
For the same reason, the discussion itself belongs in CFRG,
where it would get review from the crowd focused on
cryptographic mechanisms.
Cheers, Kris
_______________________________________________ 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]
