Hi John,
On 7/10/26 13:07, John Mattsson wrote:
> 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."
>
We have a shared interest and goal.
> 1. Your comments to NIST, submitted after the public discussion had
> already taken place,
That's correct. My comments to NIST are part of the NIST process and I
disagreed with the decision announced. Re-litigating it on the mailing
list was an option. I waited and used the official NIST process because
I saw that the well reasoned arguments including by Prof. Dr Peter
Schwabe, a Kyber designer, and Dr. Bas Westerbaan were not actually
addressed sufficiently.
> were not very convincing
If you need to be convinced to take a conservative approach in
cryptography, I am not sure what to tell you. Here's what I think was
not convincing: The removal was not sufficiently motivated. None of the
reasons raised actually proposed a solution that destroyed the algebraic
structure of Dual_EC_DRBG and the result most certainly did not remove
the specific cryptographic oracle in TLS that was raised.
The removal of the hash function was done despite objections from at
least one Kyber designer in that very mailing-list thread, and this is
similar to pushing for non-hybrid deployments of ML-KEM.
> and were almost entirely devoid of technical details.
That's an unfair characterization but I understand that there is a gap
in your understanding here. I apologize if my emails aren't clear enough
due to their length and the need to read the citations.
> 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.
This is not the issue that I raised in my comments. The entropy of the
RNG output is not really in question. It can have very little or it can
have a lot. Thus, we can say that we agree - hashing generally won't add
entropy, it may remove a negligible amount of entropy. When performed
competently and with sufficient input entropy, hashing can act as a
strong extractor-like post-processing step. But my point is not entropy
accounting; it is destroying hidden algebraic structure. Hashing with
the public key may be useful but indeed, to a third-party adversary that
sees the public key, it will not _increase_ entropy.
Entropy however was not the issue raised and it is still not the issue.
Anyone who is raising entropy is distracting from the discussion of a
covert channel, introduced by poorly motivating a removal of a hash
function that was added exactly to ensure that hidden structure would be
destroyed.
> 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.
This is exactly why the entropy discussion is a sideshow. It confuses
the issues.
First, we need a good source of entropy, we agree.
Second, it does something against a controlled RNG of a very specific
kind: a Dual_EC_DRBG-shaped backdoor which may be in your hardware (good
luck finding it without a whistleblower!) or it may be in your software
and indeed Reuters reported that RSA accepted $10,000,000 under a secret
NSA contract to make Dual_EC_DRBG the default in BSAFE. Juniper
similarly had this in their ScreenOS releases though originally with
slightly different parameters than what NIST standardized. Later, an
attacker changed these parameters to repurpose the backdoor for their
own interests. Most people suspect a different large-scale adversary
than the NSA but only time will tell.
Third, the "correct" fix is subjective. Here's what I think would be the
correct fix: the correct fix is a fix that addresses the different
concerns in a systematic manner such that attacks are stopped. Yes, we
want a better RNG outside of ML-KEM. No, it is not sufficient to say
"use a better RNG" when the required RBG framework is the same standards
framework that previously included Dual_EC_DRBG.
> 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?
I have explained the attack several times and I am starting to think
that you want or need to see some code run to fully understand what I am
saying.
Would you like an attack demo showing how raw Dual_EC_DRBG-shaped output
used as `m` gives the decapsulating peer an RNG-state-recovery sample?
Be specific, please.
This classroom demo uses full 32-byte x-coordinate blocks; the standard
truncated-output recovery variant adds candidate enumeration, not a
different principle. I have also implemented the attack against the
truncated version with arbitrary truncation in either direction. The
only question is how much CPU power that one wants to spend.
./verify_two_encaps demo.json
OK e = SHA256(q_label) mod n == params.secret_e
OK Q = e*P and d = e^-1 and d*Q == P
OK s1..s4 = x(s*P) mod n
OK block_i = big-endian x(s_i*Q)
OK recipient (ek,dk) = KeyGen_internal(0^32,0^32)
OK ct1 = Encaps_internal(recipient ek, m1)
OK next keypair = KeyGen_internal(block_3, block_4)
OK s2 recovered from m1 alone
OK Kyber-768 decapsulates SHA3-256(m1), not m1
verdict: ATTACK SUCCEEDS against ML-KEM when m is raw Dual_EC_DRBG output;
verdict: PROTECTED against this Dual_EC_DRBG oracle by Kyber m<-H(m)
ALL CHECKS PASSED
Here's an alternative verifier for the same json output file:
./verify_json demo.json
== verify demo.json ==
OK scheme
OK kem
OK kem_spec
OK e = SHA256(q_label) mod n
OK d = e^-1 mod n
OK Q = e*P is on P-256
OK Q.x
OK Q.y
OK d*Q == P
OK json d_times_Q_equals_P
OK s1 = x(s0*P) mod n
OK s2 = x(s1*P) mod n
OK s3 = x(s2*P) mod n
OK s4 = x(s3*P) mod n
OK block_1_m1 = I2OSP_32(x(s1*Q))
OK block_2_m2 = I2OSP_32(x(s2*Q))
OK block_3_keygen_d = I2OSP_32(x(s3*Q))
OK block_4_keygen_z = I2OSP_32(x(s4*Q))
OK observed m1 == block_1_m1
-- trapdoor recovery from m1 --
OK m1 is a valid P-256 x-coordinate
OK candidate recovery set is non-empty
OK s2 recovered from m1 alone
OK json recovered_state_s2
OK predicted next m == block_2_m2
OK json next_m_predicted
-- ML-KEM-768 internal checks --
OK recipient ek = KeyGen_internal(0^32,0^32).ek
OK recipient dk = KeyGen_internal(0^32,0^32).dk
OK ct1 = Encaps_internal(recipient ek, m1)
OK instrumented decapsulation recovers m1
OK json decaps_recovers_m1
OK next ek = KeyGen_internal(block_3, block_4).ek
OK next dk = KeyGen_internal(block_3, block_4).dk
OK json next_keypair_predicted
-- Kyber-style m <- H(m) check --
OK Kyber recovered value == SHA3-256(block_1)
OK Kyber recovered value != raw m1
OK json equals_SHA3_256_of_block_1
OK json kyber state_recovery_possible
OK truncation.bits
OK truncation.candidates_enumerated
OK truncation.true_state_found
-- verdict --
ATTACK SUCCEEDS against ML-KEM when m is raw Dual_EC_DRBG output;
PROTECTED against this Dual_EC_DRBG oracle by Kyber m<-H(m)
ALL CHECKS PASSED (40 checks)
Would you like a Sage script to check the math? Would you like me to
show you how to generate the custom parameters?
Do you want to see this applied to TLS 1.2 or TLS 1.3?
> 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,
I am not sure what national or regional origin has to do with the
technical issue. Many European cryptographers disagreed with this
change, myself included.
It was opposed by a Kyber designer in the very thread but to your odd
nationality point, he too is a distinguished European professor. It was
also opposed by others in that discussion.
With regard to trust, well, that is indeed an important factor. I am not
questioning who you trust, that is up to you.
I am sure the environment is ever so slightly less destroyed by the
computational load of various defense contractors not making that single
hash call.
Anyway, I do not see anyone disputing the narrow technical point:
hashing `m` destroys the Dual_EC_DRBG-shaped algebraic structure, while
removing that hash preserves it for the decapsulating peer.
> why do your conspiracy theories not mention the EU and European
> SIGINT agencies?
>
What specifically are you calling a conspiracy theory? I understand that
you work for Ericsson. This is the company which was famously involved
in the Athens Affair [0]. If you're doing security for them, I sure hope
you take these kinds of things seriously.
Please be direct and cite or quote me exactly. I will back up what I
have written. I will either provide you with documents or a coherent
explanation.
If you are unable to back up your statement, I politely request that you
withdraw your characterization of "conspiracy theories" and use a more
proper term namely government and business _plans_.
I have based my comments and my work on solid evidence that comes from
sourcing inside and outside of the NSA, and it is often supported by the
NSA's own classified documents. I have provided ample citation
documentation and I wonder if you even bothered to read it?
My reporting has most certainly mentioned the EU and European SIGINT
agencies, especially GCHQ. My reporting on this general topic has been
cited by both the German and the European Parliament.
The EU has primarily been a target, similar to the UN, and again these
are established facts. Reasonable people disagree if they are happy with
the previous or even the current US administration doing these things.
This is just how the sausage is made. To that point: NSA doesn't even
deny these matters when challenged as part of routine confrontations for
a comment on these kinds of stories. Usually a denial is a problem when
they're caught red handed and in those cases NSA's spokesperson will
often justify the activity in question as legal.
> 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.
>
On this, we can probably find some agreement. Currently, I do not agree
that it is too late. The best time to start is usually in the past and
the next best time is now. Tomorrow is alright too.
I am happy to work with you or others to find a way to advance greater
defense in depth against entropy related issues. I would also be
interested in extending that work to cover destroying hidden structure
carrying covert channels. One without the other is a recipe for disaster.
Kind regards,
Jacob Appelbaum
[0] https://spectrum.ieee.org/the-athens-affair
> Cheers, John Preuss Mattsson
> 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
>
> [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
>
>
OK truncation.true_state_found
-- verdict --
ATTACK SUCCEEDS against ML-KEM; PROTECTED by Kyber m<-H(m)
ALL CHECKS PASSED (40 checks)
Would you like a Sage script to check the math? Would you like me to
show you how to generate the custom parameters?
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,
I am not sure what national or regional origin has to do with the
technical issue. Many European cryptographers disagreed with this
change, myself included.
It was opposed by the main submitter of Kyber in the very thread but to
your odd nationality point, he too is a distinguished European
professor. It was also opposed by others in that discussion.
With regard to trust, well, that is indeed an important factor. I am not
questioning who you trust, that is up to you.
I am sure the environment is ever so slightly less destroyed by the
computational load of various defense contractors not making that single
hash call.
Anyway, I don't see anyone claiming that the removal of the hash
destroys hidden structure. So, I guess you're talking about trust but
not trusting them that the hidden structure is destroyed.
why do your conspiracy theories not mention the EU and European
SIGINT agencies?
What specifically are you calling a conspiracy theory? Don't you work
for Ericsson? The company famous for the Athens Affair [0]? If you're
doing security for them, I sure hope you take these kinds of things
seriously.
Please be direct and cite or quote me exactly. I will back up what I
have written. I will either provide you with documents or a coherent
explanation.
If you are unable to back up your statement, I politely request that you
withdraw your characterization of "conspiracy theories" and use a more
proper term namely government and business _plans_.
I have based my comments and my work on solid evidence that comes from
sourcing inside and outside of the NSA, and it is often supported by the
NSA's own classified documents. I have provided ample citation
documentation and I wonder if you even bothered to read it?
My reporting has most certainly mentioned the EU and European SIGINT
agencies, especially GCHQ. My reporting on this general topic has been
cited by both the German and the European Parliament.
The EU has primarily been a target, similar to the UN, and again these
are established facts. Reasonable people disagree if they are happy with
the previous or even the current US administration doing these things.
This is just how the sausage is made. To that point: NSA doesn't even
deny these matters when challenged as part of routine confrontations for
a comment on these kinds of stories. Usually a denial is a problem when
they're caught red handed and in those cases NSA's spokesperson will
often justify the activity in question as legal.
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.
On this, we can probably find some agreement. Currently, I do not agree
that it is too late. The best time to start is usually in the past and
the next best time is now. Tomorrow is alright too.
I am happy to work with you or others to find a way to advance greater
defense in depth against entropy related issues. I would also be
interested in extending that work to cover destroying hidden structure
carrying covert channels. One without the other is a recipe for disaster.
Kind regards,
Jacob Appelbaum
[0] https://spectrum.ieee.org/the-athens-affair
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
[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]
