Hi Eliot,
Thanks for your reply. I am not claiming that ML-KEM is itself an
intentionally placed undisclosed back door.
Please see my comments below.
On 7/8/26 11:35, Eliot Lear wrote:
Hi!
~~~~Disclaimer
I'm not a cryptographer.
~~~~>
Please see below.
On 08.07.2026 08:04, Viktor Dukhovni wrote:
On Tue, Jul 07, 2026 at 10:27:56PM -0700, Christian Huitema wrote:
I just read Jacob Applebaum's message. Given his description of the
late-standardization suspicious change that looks like a backdoor in the
ML-KEM specification, I agree with his conclusion. The WG should not
ask for
publication of the current graph, not until the changes requested by
Jacob
are made.
The removal of whitening of the `m` random input to Encaps is not a
plausible backdoor. If all you have is a broken RNG, you're free to
apply whitening to obtain a new less bad RNG and use that instead.
Nothing stops an ML-KEM implementation from hashing some input (any
number of times, mixing in whatever additional inputs, ...) to produce
its random values. The abstract algorithm starts from the final output
of an adequate RNG that requires no further post-processing.
There's nothing suspicious about this simplification. The critique in
question makes no sense to me. Don't use a broken RNG.
That sounds about right to me, but as someone who is not a
cryptographer, perhaps someone who is could explain how this amounts to
a back door, and not a requirement for a good PRNG? And if it's not a
back door, should we really relitigate NIST's choices here?
Eliot
* By "back door", I mean an intentionally placed undisclosed weakness
that could be exploited by the people who placed it there.
The issue is that NIST removed a defense-in-depth step from Kyber. Kyber
hashed `m` and explicitly said "Do not send output of system RNG." FIPS
203 removed that hash and justified the change by _requiring_
NIST-approved randomness generation. That requirement is not stated in
the security considerations of the draft under discussion.
That change also coincidentally _creates_ a covert channel. It becomes
dangerous when another layer supplies a sabotaged RNG. Users and/or
servers generally do not know when they have a sabotaged RNG, so we
should close such channels when the fix is cheap.
In TLS 1.3, a client can send an ML-KEM key share, receive a server
ciphertext, and recover the server's internal `m` by instrumenting its
own decapsulation. If `m` comes directly from a Dual_EC_DRBG-shaped RNG,
this gives the client an oracle on server RNG output. Restoring Kyber's
original `m <- H(m)` destroys the structure of that oracle.
This is why Extended Random is relevant here: it would have made
Dual_EC_DRBG easier to exploit by exposing more RNG-derived material. We
rightly consider that a scandal. Here, again, NIST influence removed a
simple defense-in-depth step from a sound Kyber design. It is reasonable
to worry about NSA influence given NIST's statutory obligation to
consult with other agencies, including NSA, when developing such
standards and guidelines.
Similarly in this draft, the security considerations ignore the Kyber
team's own advice about hybrids where they state [0]:
'Use Kyber in a so-called hybrid mode in combination with established
"pre-quantum" security; for example in combination with elliptic-curve
Diffie-Hellman.'
So no, this is not just relitigating NIST. The TLS WG is deciding
whether to publish a TLS use of standalone ML-KEM that inherits this
assumption. The draft should restore the Kyber-style hash over m, or
clearly state the FIPS 203 randomness-generation dependency and its
consequences.
Kind regards,
Jacob
[0] https://pq-crystals.org/kyber/index.shtml
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
