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
[1]
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/MRa5O0CvAAAJ
[2] https://rwc.iacr.org/2015/Slides/RWC-2015-Kelsey-final.pdf
[3]
https://csrc.nist.gov/csrc/media/projects/crypto-standards-development-process/documents/dualec_in_x982_and_sp800-90.pdf
[4] https://csrc.nist.gov/glossary/term/covert_channel
[5] https://rump2007.cr.yp.to/15-shumow.pdf
[6] https://eprint.iacr.org/2015/767
[7]
https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-checkoway.pdf
[8]
https://www.reuters.com/article/world/exclusive-secret-contract-tied-nsa-and-security-industry-pioneer-idUSBRE9BJ1C5/
[9]
https://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security
[10] https://datatracker.ietf.org/doc/html/rfc3935
[11] https://datatracker.ietf.org/doc/html/rfc7258
[12]
https://archive.nytimes.com/www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
