Hi John,
On 7/13/26 17:36, John Mattsson wrote:
I think it is reasonable to assume that nation-state attackers have
the resources to search extremely large seed spaces.
Sure. That is a different case.
If the attacker controls or can search the seed, then many constructions
fail. My point is about the case where the attacker does not know the
current state, but can recover it from structured output. Dual_EC_DRBG
is the public example of that class.
I don't think I mentioned entropy, but entropy is very useful. As
noted, m = H(m, independent entropy), where the entropy comes from
any source other than the attacker-controlled RNG, thwarts a much
larger class of attacks than m = H(m).
Agreed, if independent entropy is actually available and specified but
it introduces lots of pointless debating we can skip by restoring the
original design of this exact part of Kyber, and nothing more.
But that is not the current draft. The current issue is that NIST
removed Kyber's hash over `m`. Restoring `m <- H(m)` is sufficient to
destroy the Dual_EC_DRBG-shaped structure. It does not solve every
attacker-controlled RNG, and it does not need to.
I don't think it is helpful to focus on Dual_EC_DRBG except as a
historical example. I think the discussion should focus on attacker-
controlled RNGs in general.
Dual_EC_DRBG is a historical example, but it is also the concrete
standardized example of the exact hidden-structure failure mode. That is
why it is useful. It is also sadly, not actually entirely historical.
Just in the Bouncy Castle case, we're talking about hundreds of millions
of downloads that include Dual_EC_DRBG. It is probably one of the most
popular Java libraries for cryptography.
I agree that the broader class should also be addressed. But the
existence of a broader class is not a reason to leave the ML-KEM `m`
case unfixed.
That still allows trivial attacks by nation-state attackers to
recover all RNG outputs. And any fix belongs in a general TLS/IETF
document.
Only for a different threat model, such as attacker-known or attacker-
searchable seeds.
For the hidden-structure case, hashing `m` removes the structure before
the peer can recover it. That is the point. This is a deployed class of
hardware backdoors. The hardware backdoor outputs get used directly in
some non-trivial cases.
I also support a general TLS/IETF document. But this draft is where the
ML-KEM `m` oracle is being introduced into TLS, so the draft should fix
or at least not preserve that problem.
I think applications using ML-KEM should mix multiple entropy
sources, continuously add fresh entropy, and hash the resulting
output before using it in ML-KEM or any other part of IETF
protocols. Even if an application only performs m = H(m), which is a
very weak solution, I think such mitigation belongs at the TLS/IETF
level rather than at the algorithm level.
I agree with the first sentence as general guidance.
I disagree that `m <- H(m)` is too weak to require here. It is weak only
if it is being advertised as a complete RNG architecture. I am not doing
that. I am saying it closes this specific peer-recoverable hidden-
structure channel _which was reintroduced by NIST_ such that an entire
class of security issues was relevant again.
So I think the right outcome is both:
- restore Kyber's hash over `m` in the TLS ML-KEM drafts;
- separately pursue broader TLS/IETF guidance for all protocol-visible
and peer-recoverable randomness.
I disagree that this is the relevant threat model.
Then this may be the real disagreement.
The threat model is not invented: NIST standardized Dual_EC_DRBG, and
NIST removed a Kyber defense-in-depth step that blocks the relevant
structure. That makes the model directly relevant to this discussion.
If this isn't your threat model, I wonder if this is also Ericsson's
position? For example - if some regulatory body in the EU _required_
this hash be restored for sales, similar to FIPS certification, would
that change your position?
What kind of evidence do you require to change your mind? Do you need a
working demonstration where the secret keys are available to you?
Kind regards,
Jacob Appelbaum
On 2026-07-13, 16:08, "Jacob Appelbaum" <[email protected]> wrote:
Hi John,
On 7/13/26 15:17, John Mattsson wrote:
In addition to RSA-PSS and RSA-OAEP, randomized symmetric
encryption also reveal randomness.
To further explain some of the cases where randomness are
revealed:
- RSA-PSS reveals the random salt. - RSA-OAEP reveals the random
seed. - RSA-KEM reveals the random integer z. - All key transport
algorithms reveal the randomly generated DEK. - GCM with random
IVs, and nonce-key derivation (NKD) algorithms such as draft-
gueron-cfrg- dndkgcm, reveal the random nonce. - Random GREASE
values or random permutations of protocol reveal randomness.> -
Privacy mechanisms using random padding or random-length padding
reveal randomness.
- Privacy mechanisms using random packet timing reveal randomness.
Agreed on the broader pattern, with one important distinction: some
of these values are protocol-visible to passive observers, while
others are recoverable only by the peer that holds the corresponding
private key or decapsulation key.
That distinction matters for threat modeling. RSA-PSS salts, random
IVs, GREASE values, padding lengths, and timing are visible to
observers. RSA-OAEP seeds, RSA-KEM z values, transported DEKs, and
ML-KEM `m` are better described as peer-recoverable. They are not
all the same channel, but they are all worth reviewing if they may
carry structured output from a kleptographic RNG.
So yes: this class of issue is broader than ML-KEM. That strengthens
the case for systematic TLS review. It does not weaken the case for
fixing ML-KEM now.
To further explain more general attacker-controlled RNGs:
A trivial attack using an attacker-controlled RNG is to provision
a known seed s and then generate a deterministic random stream as
a function of s. The state update and output function could e.g.,
be implemented as a hash-based ratchet, where the outputs are:
s, H(s), H(H(s)), H3(s), ...
Given any output value H^i(s), the attacker can recover s and
derive all previous and future outputs.
If the attacker provisioned or otherwise knows `s`, then yes,
future outputs are predictable.
If the attacker only sees `H^i(s)` from a secure hash chain, they
can compute later values, but they generally cannot recover earlier
values or `s` without inverting the hash or searching a small seed
space. So I would separate those cases:
- attacker-known seed: future stream is known immediately; - output-
as-state hash chain: seeing one output predicts future outputs; -
Dual_EC_DRBG-shaped output: trapdoor holder can recover internal
state from structured output and then predict future outputs.
The last case is the one I am focused on for ML-KEM `m`.
Redirecting to talk about entropy is unhelpful.
Deterministic ratchets of this type are weak. They provide no
protection for future outputs after state compromise, and if the
initial value s is recoverable, they provide no protection for
past outputs either. 128-bit of revealed randomness is more than
enough for the attacker to find the correct s. Additional side
information can further reduce the search space and make recovery
easier.
Agreed in spirit, but I would avoid saying 128 bits is "more than
enough" in the abstract. It depends on the seed distribution,
attacker knowledge, and whether the construction has trapdoor
structure. For Dual_EC_DRBG-shaped output, the structure is the
point; this is not ordinary entropy accounting.
This type of backdoored, attacker-controlled RNG is not a new
idea. It likely existed long before Dual_EC_DRBG and likely still
exists today. Dual_EC_DRBG was not a fundamentally new attack
concept; it was an optimization and standardization of an existing
idea.
New isn't the issue. The issue is harm minimization against an
extremely stable, absolutely unnecessary cryptographic oracle. The
fact that this class of attacks is old is why it should have been
systematically eliminated by NIST during standardization, including
when it was raised in official comments in _2023_. That Dual_EC_DRBG
is the public, standardized, well-studied example from NIST where
everyone including NIST agrees that it was NSA's sabotage is what
makes this embarrassing to not mitigate then and it is even more
embarrassing now.
That history is enough to justify defense in depth against this
class and especially in a non-hybrid construction or a hybrid
construction where the oracle could lead to breaking both PQ and T
primitives.
On 7/13/26 12:42, John Mattsson wrote:
Hi Nick,
Some comments:
- The distinction between passive and active adversaries is
correct, but is it useful to make that distinction in this
context? In some cases, it may be difficult to protect against
active attackers, and one may need to settle for a passive
security goal. In this case, however, I think we should aim to
protect against both.
Yes, we should aim to protect against both.
I still think the distinction is useful because it tells us where
the oracle appears. TLS public random fields are passive-visible.
ML- KEM `m` is peer-recoverable. Both can be dangerous, but they are
not the same channel.
- I do not think focusing on algorithms is the right approach for
the IETF. We should consider all protocol fields that reveal
randomness. Even when considering algorithms, modern RSA
algorithms, as well as encryption schemes used for key transport,
reveal randomness.
So, you want to... leave ML-KEM alone and not hash it even though it
is wire-compatible but returns us to the safer Kyber design?
We should systematically review all protocol-visible and peer-
recoverable randomness in TLS.
But the ML-KEM case is already in front of the WG, and it has a
simple fix: restore Kyber's hash over `m`, or use an equivalent
context-bound derivation that destroys hidden structure before
encapsulation.
- Regarding the statement: "For a Dual_EC-shape DRBG a single 32-
byte m is enough. Other state-recoverable constructions may
require more." An attacker who knows the initial state of a
deterministic DRBG typically needs much less than this to recover
future outputs.
Agreed if the attacker already knows the state. But that is not the
Dual_EC_DRBG trapdoor model I have consistently raised. This is why
your proposals are insufficient technically to address the class of
attacks.
The relevant model is: the attacker does not know the current state,
but can observe enough structured output to recover it. For
Dual_EC_DRBG- shaped output, a 32-byte `m` is close to ideal. A
truncated value is also fine as long as the truncation is
computationally feasible to enumerate. Other constructions may need
different amounts, different side information, or may simply be
known to the attacker from the start.
So I think we agree on the broader lesson: RNG state should not
cascade across TLS connections, and structured random-generator
output should not be exposed through protocol-visible or peer-
recoverable values.
For the current drafts, that means: fix ML-KEM `m` by hashing it now
as Kyber did, cite Kyber's rationale, cite the relevant
Dual_EC_DRBG history, and then we should also do the broader TLS
review. Other protocols should follow.
Kind regards, Jacob Appelbaum
From: Nick Sullivan
<[email protected]<mailto:[email protected]>>
Date: Monday, 13 July 2026 at 11:59 To:
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>> Subject: [TLS] RNG state
should not cascade across TLS connections
Hi TLSWG,
Pulling this up from a deep subthread so it doesn't get lost.
There are two distinct attacks against a state-recoverable DRBG
worth naming separately. Both work the same way: one exposure of
RNG output lets the attacker walk state forward and predict every
subsequent draw from the same DRBG.
Scenario 1: passive eavesdropper. Recovery vector is a wire nonce
like ServerHello.Random. Applies to both KEMs and DH.
Scenario 2: adversary client. Recovery vector is `m`, which the
adversary recovers by decapsulating the server's ciphertext.
Applies to KEMs only, not to DH.
Scenario 2 applies to KEMs but not DH because the FO transform
requires the decapsulator to recover the encapsulator's `m`. DH's
peer sees only `a·G` behind ECDLP. No raw randomness ever
crosses. This is a KEM-abstraction property, not ML-KEM-specific.
The attacker in Scenario 2 needs to make enough connections to
your server to accumulate the `m` values needed to recover DRBG
state. For a Dual_EC-shape DRBG a single 32-byte `m` is enough.
Other state- recoverable constructions may require more.
What both scenarios share: once DRBG state is recovered, the
attacker passively decrypts every subsequent connection to that
server from just the network flow. Every user, every session,
decrypted from the wire without touching the server again. This
continues until the DRBG reseeds. For a stack that does not
explicitly reseed, that means for the life of the process.
Predicted `m` plus observed `ek` gives the KEM shared secret
directly. This is the mechanism behind the 2015 Juniper ScreenOS
Dual_EC incident, which put passive VPN decryption within reach of
whoever held the trapdoor to the substituted Q constant. Nothing
about ML-KEM makes it immune to the same mechanism. That cascade
is the actual concern.
How the server arranges its DRBGs determines which scenario the
attacker would take. Under a shared DRBG (ServerHello.Random and
`m` from the same source), Scenario 1 is available to any passive
observer without an active connection. This is Ben Kaduk's point.
Splitting the DRBGs closes Scenario 1 but leaves Scenario 2 as
the primary path against the DRBG that feeds `m`.
David Benjamin has argued that the fix belongs at the RNG layer,
not at ML-KEM or inside TLS. That seems right. Use a DRBG whose
output does not reveal its state (duh), and which provides post-
compromise recovery (via reseeding from fresh entropy by design,
or via per- connection reinitialization at the caller). Either
way, any state exposure is bounded in time. This approach is KEM-
generic and applies beyond ML-KEM.
Runnable PoCs for both scenarios are trivial to construct.
Let me know if I have this summary right.
Nick
_______________________________________________ TLS mailing list
-- [email protected]<mailto:[email protected]> To unsubscribe send an email
to [email protected]<mailto:[email protected]>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
