Hello Thom,
On 7/8/26 11:52, Thom Wiggers wrote:
Hi,
ML-KEM is arguably not backdoorable unless you break the RNG. Bad
RNG is something that we can’t really protect against anyway.
We can easily protect against this exact concern with a single hash
function call over the system randomness.
After that fix is applied, we can return to the regularly scheduled
lattice security assumption concerns. I look forward to seeing further
discussions on power-of-two cyclotomics as Tanja Lange mentioned in her
earlier email.
My point about the hash over `m` is that we should ensure that the
lattice related security assumptions in the cryptographic primitive are
the relevant security assumptions!
ML-KEM's security does not require `m` to come directly from the system
RNG without hashing, and it does no harm to hash `m` at all except to
users of the covert channel. It will stop this very specific
exploitation technique. The computational cost is minimal and literally
all of the computational cost is wasted if the covert channel is used.
Classic cryptography is also broken if the RNG is busted.
Sure, kinda, maybe, usually. Oddly though: X25519 probably does not fall
from this specific kind of RNG sabotage unless ML-KEM leaks the
sabotaged RNG state first because it is not a lack of entropy but a
covert channel. It is unfortunate that (many) implementations of TLS
(1.3) tend to write system randomness directly into randomized fields
which is then visible on the wire to a passive adversary.
Consider why the Extended Random draft was desirable from an adversarial
perspective: leaking the sabotaged RNG state allows for side stepping
the fundamental hardness assumptions of the cryptographic primitive
protecting the contents of the protocol run.
Finally,
the TLS key schedule still mixes in all messages from both sides
rendering the point moot for TLS.
This response suggests a misunderstanding of how large-scale adversaries
will exploit the issue that I have described.
Kind regards,
Jacob Appelbaum
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
