Hi Nico,
On 7/10/26 20:54, Nico Williams wrote:
On Fri, Jul 10, 2026 at 11:07:45AM +0000, John Mattsson wrote:
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?
Suppose the RNG outputs 32 byte outputs where the first 40 bits are an
index that can be used by the attacker to recover the remaining 216 bits
when the attacker also knows part of a seed for the RNG. In this case
the attacker must see those 40 bits in order to recover the remaining
216 bits, but hashing means they will not see them and will have too-
large a work factor to recover the original `m`.
With a lot of respect, no. Attacking the seed again confuses the issue.
The attack works without knowledge of the Dual_EC_DRBG seed.
However, as noted, the nonces too need to be hashed RNG outputs to
defeat such an attack.
There are two parts: ML-KEM and TLS. For ML-KEM, we only need a single
ML-KEM.Encaps() that samples from the system RNG where the RNG is
Dual_EC_DRBG in hardware or software, and then we can reconstruct the
RNG's internal state by attacking `m`. If `m` is the usual truncated
Dual_EC_DRBG output then we only have to do a small amount of work to
recover (~2^16) the internal state.
Of course the attacker could just provide the victim with an RNG where
the attacker just knows the seed and only needs to know the index of RNG
outputs corresponding to `m`. In this case the attacker would only have
to brute-force a small index, and now hashing `m` does nothing to
protect the victim.
This is speculative and distracts from the actual attack I have
described in painstaking detail.
So in a way hashing `m` adds no value because if the attacker knows
you'll be hashing `m`: since we're talking about an attacker that can
convince you to use their RNG they can just make you use one where
hashing `m` achieves nothing.
Bouncy Castle ships Dual_EC_DRBG today and it contains the original NIST
parameters that are understood to be an NSA backdoor.
I urge you to evaluate the attack against this example which is a
reality and can be installed with a single package on Debian or Ubuntu.
It even has a nice feature of allowing you to set your own parameters in
place of NIST so you can simulate attacking Juniper's ScreenOS backdoor
Dual_EC_DRBG fiasco in just a few lines of code.
I am happy to share code if this in doubt. Please contact me off list.
But it might be more difficult to switch out the RNG at this late a
stage. On that basis one might recommend some application level
whitening of RNG outputs: on the off chance that the attacker was in
fact counting on the use of raw RNG outputs for `m` [and nonces].
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.
Indeed. Even further, apps should do this too on top of what the OS
does.
The fast key-erasure RNG design is a nice example of how to do this safely.
Kind regards,
Jacob Appelbaum
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
