[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08)

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]