[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08)

Hi Uri,

On 7/10/26 17:36, Blumenthal, Uri - 0553 - MITLL wrote:
> An excellent answer, IMHO. I fully concur.
> 

Nice of you to "fully concur" with him, conspiracy theory jab and all.

Nothing being discussed here is a conspiracy theory. Refusal to address 
the technical issue of destroying any possible hidden structure is the 
issue. My core concern has nothing to do with entropy. The hidden 
structure inherent in the covert channel, encrypted or not, and the 
oracle when composed with TLS is a problem with any amount of entropy.

In any case I find your response strange because of your previous 
comments in the NIST pqc-forum thread.

In the NIST thread about this issue you advocated for not removing the 
`m <- H(m)` step by saying: "...Needless to say, in this argument I’m 
100% on the practitioners’ side, and fully support hashing the RNG 
output. Even if in many cases it is unnecessary. My use cases can afford 
it, and, most likely, so can yours. ..." [0]

Later, after the Panos's benchmarking showed [1] the costs to be minimal 
and he stated:

   "In my opinion, 300-1500 cycles are negligible for most use-cases. 
Even 5% for a well-performing algorithm like Kyber is insignificant. 
Personally I think that keeping the hash in the spec is probably worth 
it as a defense-in-depth mechanism as mentioned previously in this 
thread." [1]

In the same email he also added:

   "Implementations that consider it important to shave a little more 
from encapsulation could chose to omit the hash by taking into 
consideration the theoretical concerns (laid out in this thread). Maybe 
this could even be documented in the spec."

You replied and stated that the cycle cost email from Panos was enough 
to settle it:

   "I completely agree with Panos here. Given the data he presented, it 
doesn’t make sense to keep arguing." [2]

After NIST announced their change [3], the thread ended with no further 
replies from you or anyone else.

Changing your mind is probably reasonable. Please enlighten us: What 
changed other than NIST's declaration that the matter was settled 
exactly opposition to your very own stated goals and analysis?

Kind regards,
Jacob Appelbaum

[0] 
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/LoYaCrRbBAAJ

[1] 
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/d8SFB2RhAAAJ

[2] 
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/5-oi9qNkAAAJ

[3] 
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/MRa5O0CvAAAJ

> 
> --
> V/R,
> Uri
> 
> 
> There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.
> The other is to make it so complex there are no obvious deficiencies.
> C. A. R. Hoare
> 
> 
> From: John Mattsson <[email protected]>
> Date: Friday, July 10, 2026 at 07:08
> To: Jacob Appelbaum <[email protected]>; [email protected] <[email protected]>; Tanja Lange <[email protected]>
> Cc: [email protected] <[email protected]>
> Subject: [EXT] [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
> 
> 
> 
> Hi Jakob,
> 
> 
> Protecting against attacker-controlled random number generation is a topic I care deeply about and frequently comment on, as illustrated by my comments on FN-DSA.
> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/1HXzjlMUU6Y/m/HUXz-ml0AQAJ
> 
> 
> "Beyond accidental misuse (e.g., the PS3 software signing incident) or malfunctioning HRNGs, there is a significant risk of backdoored HRNGs. Alarmingly, some QRNG vendors make claims that their products are unbreakable and that the output can be used directly for cryptography without a CSPRNG. This is exactly the kind of statements one would expect from a hardware vendor secretly influenced by a SIGINT organization.
> 
> 
> If NIST is not already doing so, I strongly believe you should recommend the use of multiple independent entropy sources in all cryptographic applications to mitigate both accidental and intentional weaknesses. It is impossible to verify the security of a black-box HRNG."
> 
> 
> 1. Your comments to NIST, submitted after the public discussion had already taken place, were not very convincing and were almost entirely devoid of technical details. My understanding after following the discussion on the PQC Forum was, and still is:
> 
> 
> The m <- H(m) step does not strengthen security against a weak RNG because it neither adds entropy nor protects a value that the attacker can observe. It only helps in the narrow case of a biased-but-entropic RNG, does nothing against a fully broken/controlled RNG, and the correct fix for either case is to improve RNG outside of ML-KEM rather than papering over a bad RNG inside ML-KEM itself.
> 
> 
> Could you provide a detailed technical explanation of how an attacker controlling the RNG could break ML-KEM but not Kyber with the m ← H(m) step?
> 
> 
> 2. As the removal of m <- H(m) was proposed by a distinguished European cryptographer (who I trust), formerly with SSH and recently heavily involved in several EU cryptography initiatives, why do your conspiracy theories not mention the EU and European SIGINT agencies?
> 
> 
> 3. It may be too late now, but I strongly believe RFC8446bis should recommend the use of multiple independent entropy sources to mitigate both accidental failures and intentional weaknesses. RFC 8937 is one way to achieve this, but it is neither the only approach nor necessarily the best one. Many operating systems already combine multiple entropy sources, including keyboard and mouse interrupts, USB events, network and storage timing, scheduler timing, CPU hardware RNGs, TPM RNGs, EFI RNGs, and CPU jitter.
> 
> 
> Cheers,
> John Preuß Mattsson
> 
> 
> On 2026-07-09, 18:11, "Jacob Appelbaum" <[email protected]> wrote:
> 
> 
> Hi Henrick,
> 
> 
> On 7/9/26 10:39, Henrick Hellstrom wrote:
> 
> 
>> On 2026-07-09 10:10, Tanja Lange wrote:
>>
>>> The question by Benjamin Kaduk was if there are cases where the
> server hellow would not leak the state of the PRNG (adding P for
> clarity^*) and Botan implements that protection. There are other
> libraries that have seperate PRNGs for public and private values.
> 
> 
> To further support Tanja's point: The sub-topic is not ordinary PRNG
> quality. It is avoiding leakage of bytes that can form a covert channel
> and carry algebraic structure from kleptographic RNGs such as
> Dual_EC_DRBG. That kind of leakage can happen through many protocol
> fields, including TLS fields, and it is a specification-level defense-
> in-depth gap.
> 
> 
> ML-KEM as finalized in FIPS 203 removed Kyber's hash over `m`, even
> though at least one Kyber designer explicitly argued that hashing `m`
> avoids sending system RNG output to the recipient [0]. NIST later
> announced that the hash would be removed [1]. I have not seen an
> analysis from NIST showing that this removal remains safe against their
> own historical example: Dual_EC_DRBG, a DRBG NIST described as "provided
> by NSA," which NIST later said there were many reasons to reject or
> modify, but "instead, we left it in" [2][3].
> 
> 
> Any such analysis would have had to address the central point: hashing
> destroys the Dual_EC_DRBG algebraic structure needed for efficient state
> recovery.
> 
> 
>> Yes, but just hashing the output from a DRBG is not the approved way
> to do it. Instead you are supposed to spawn a secondary DRBG with a seed
> generated from a primary DRBG.
> 
> 
> That may be an approved construction for ordinary DRBG engineering, but
> it is not obviously a defense against a DRBG whose output is
> intentionally structured to leak its state. If the primary DRBG is
> Dual_EC_DRBG-shaped, spawning another DRBG from it may simply give the
> defender two things to audit. Please point me to the specific approval
> text you mean where the "do it" is defending against this class of
> Dual_EC_DRBG kleptographic backdoor.
> 
> 
> Dual_EC_DRBG output can look secure by many metrics and still act as a
> covert channel [4]. With the relevant trapdoor/secret key(s), an
> Adversary who can sample enough output can recover DRBG state and
> predict future outputs. The general attack is well established [5][6]
> [7]. The RSA/Dual_EC_DRBG reporting and the BULLRUN reporting are the
> relevant historical context here [8][9].
> 
> 
> Obviously no one should use Dual_EC_DRBG. The problem is that users
> often do not know when their randomness source is sabotaged. Hashing
> does not solve all bad-RNG problems, but it does destroy the algebraic
> structure used in this known attack class.
> 
> 
>> Just hashing wouldn't do much good, if you are really concerned that
> the DRBG output might reveal anything about the internal state.
> 
> 
> For this attack class, it does good.
> 
> 
> Hashing `m` during `ML-KEM.Encaps()`, for example with the ML-KEM public
> key and/or transcript context, binds `m` to context before the ML-KEM
> ciphertext is sent. In the normal non-ECH TLS 1.3 case, that closes the
> Dual_EC_DRBG-shaped oracle against the server's RNG output. With ECH
> using ML-KEM or a hybrid KEM, the same concern can arise in both directions.
> 
> 
> A few objections have come up repeatedly:
> 
> 
> 0. Ad-hominem attacks
> 
> 
> 1. TLS already has random fields written to the wire, so we should not
> worry about ML-KEM
> 
> 
> 2. NIST already issued FIPS 203, so the IETF should not revisit the issue
> 
> 
> 3. Updating drafts, RFCs, or implementations would be work
> 
> 
> 4. The issue also affects hybrids, so the hybrid recommendation should
> be weakened
> 
> 
> 5. Hashing may not increase entropy
> 
> 
> 6. Hashing DRBG output merely creates a new DRBG, DRBG'
> 
> 
> Briefly:
> 
> 
> 0. The IETF mission is to make the Internet work better for the people
> who use and manage it [10], and the IETF considers pervasive monitoring
> an attack [11]. Cryptographic sabotage is part of how pervasive
> monitoring becomes actionable intelligence. Attacking the person raising
> the issue is irrelevant to the technical question.
> 
> 
> 1. It is true that TLS has a broader problem with raw random bytes in
> protocol-visible fields. That is a reason to fix the broader issue, not
> a reason to preserve the same problem in ML-KEM. Tanja pointed out that
> Botan already has a TLS protection strategy. Other libraries use
> different ad-hoc strategies, or none. That is exactly why IETF guidance
> would help.
> 
> 
> 2. FIPS 203 being final is not the end of the story. NIST can publish
> errata, revisions, or clarifications. NIST withdrew Dual_EC_DRBG after
> public reporting on BULLRUN and related cryptographic sabotage. A NIST
> participant who described himself as a main author of FIPS 203 is on
> this list, and I have asked for clarification on both the hashing
> decision and the IPR implications.
> 
> 
> 3. Yes, updates take work. That is not a security argument. If the
> Security Considerations of the draft omit an important assumption and a
> cheap mitigation, that should be fixed. This is a constructive
> suggestion and an easy win to build consensus.
> 
> 
> 4. The issue also applies to hybrid X25519MLKEM* constructions. The
> answer is not to weaken hybrids; it is to hash `m` in the ML-KEM
> component. Failure to hash `m` can contribute to compromising later
> values, including later X25519 keypairs, if the same long-running RNG
> state is used and no strong reseed or unknown additional input intervenes.
> 
> 
> 5. Hashing Dual_EC_DRBG output does not magically add entropy, and may
> reduce it in some constructions. That is not the point. The point is
> destroying hidden algebraic structure. We should not shift the
> discussion from structure recovery to entropy accounting and then
> conclude that no mitigation is useful.
> 
> 
> 6. Yes, hashing DRBG output can be described as constructing DRBG'. That
> is fine. DRBG' should still be treated as suspect, but it no longer
> preserves the Dual_EC_DRBG x-coordinate structure needed by the
> published attacks. Unkeyed hashing appears sufficient to block the known
> Dual_EC_DRBG recovery attacks; a keyed hash may be useful for stronger
> designs, but it is not needed to make this point.
> 
> 
> My conclusion is simple: when history and user-centered harm reduction
> are the concern, the arguments favor hashing. We know this class of
> kleptographic attack is real. We know standards influence is part of the
> game. We should not leak raw pre-whitened system entropy to the network,
> and we should not hand raw RNG-derived `m` to a potentially adversarial
> decapsulator.
> 
> 
> To restate the completely obvious: this isn't an accusation of a
> backdoor in ML-KEM. It is a statement of fact that a defense-in-depth
> protection was knowingly removed by NIST. NIST did so over the objection
> of several people participating in the NIST PQC process, and without
> analysis that accounts for the extremely serious failures of NIST in the
> very recent past with regard to Dual_EC_DRBG. The change by NIST serves
> as an example where surprise: no one is responsible for the user's
> security even though the difference in exploitability for the
> Dual_EC_DRBG scenario is roughly a single hash function call.
> 
> 
> The IETF should give implementers clear guidance and it should be in the
> draft's Security Consideration at the very least. Hash `m`. Relatedly,
> do not write raw RNG output into protocol-visible fields when cheap
> whitening destroys known hidden structure.
> 
> 
> Kind regards,
> Jacob Appelbaum
> 
> 
> P.S.
> 
> 
> Consider also the scale of the budgets for only a single agency [12]. It
> may also be worth your time looking at the cryptographic libraries
> worked on by former NSA people once they were officially out of
> government and firmly on the defending side of the fence. It is also
> informative for spotting the folks who have retained their first job
> while taking on another, another thing we learned about PROJECT BULLRUN.
> Remember: there is no need for accusations of a conspiracy as the
> business plan as the documented [12] attack budget appears to exceed the
> IETF's operating budget by a very large margin. The larger issue isn't
> even really about the NSA as the NSA's track record serves as a fairly
> clear example of what to look for from many other large-scale adversaries.
> 
> 
> [0]
> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/o2XJ2YvfAwAJ <87a3445f-7518-46d7-891f-5d65f55bc83a>
> 
> 
> [1]
> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/MRa5O0CvAAAJ <5178f114-463b-4668-8126-2c34d95b185d>
> 
> 
> [2] https://rwc.iacr.org/2015/Slides/RWC-2015-Kelsey-final.pdf <8a20d9ec-6d3a-4565-ac8f-1556f3d366c9>
> 
> 
> [3]
> https://csrc.nist.gov/csrc/media/projects/crypto-standards-development-process/documents/dualec_in_x982_and_sp800-90.pdf <d6be5262-d3b4-4adc-963a-f52d2c2520f1>
> 
> 
> [4] https://csrc.nist.gov/glossary/term/covert_channel <035e62b4-fc2e-4457-817f-12c4ffe6c3ec>
> 
> 
> [5] https://rump2007.cr.yp.to/15-shumow.pdf <65a471bf-3ebf-43e9-acb8-96b0e98d597c>
> 
> 
> [6] https://eprint.iacr.org/2015/767 <7638077b-c04e-497e-b5e3-99cd2372acbf>
> 
> 
> [7]
> https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-checkoway.pdf <67c2c7b1-4b01-40e1-bc28-42424b2452b2>
> 
> 
> [8]
> https://www.reuters.com/article/world/exclusive-secret-contract-tied-nsa-and-security-industry-pioneer-idUSBRE9BJ1C5/ <3f0903cd-97c3-48d3-b520-eec46ca556f5>
> 
> 
> [9]
> https://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security <851c1022-6060-4dd0-8980-84c381655c51>
> 
> 
> [10] https://datatracker.ietf.org/doc/html/rfc3935 <812719c2-693f-4e26-b14a-611d64e24dff>
> 
> 
> [11] https://datatracker.ietf.org/doc/html/rfc7258 <9627d154-8684-460e-bd67-13653aac0042>
> 
> 
> [12]
> https://archive.nytimes.com/www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html <131b3b4d-f63a-4e4b-982b-1557a56c05f1>
> 
> 
> 
> 
> 

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]