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
