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]> Date: Monday, 13
July 2026 at 11:59 To: [email protected] <[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] To unsubscribe send an email to [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
