[TLS] Re: [EXTERNAL] Re: WG Last Call: draft-ietf-tl s-mlkem-08 (Ends 2026-07-08)

Hi Quynh,

Thanks for joining the discussion.

On 7/8/26 12:42, Dang, Quynh H. (Fed) wrote:
> Hi all,
> 
> See the discussion here about removing the hash of the message m.
> 
> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/
> m/qmVANi7EAwAJ
> 

I did not find the reasoning in that thread compelling in April 2023, 
and my comments were filed months later. I have still not had my 
comments adequately addressed by NIST. Please feel free to contact me 
off-list on my tue.nl university email address or privately if that 
would be more fruitful.

> The reason to remove it was that hashing m would be bad, introduce a
> cost for side-channel security implementations (ask Markku for
> detail).

The tradeoff is that removing the hash created a covert channel that 
aligns exactly with historical cryptographic sabotage concerns.

> In addition, we require an approved RBG.

I trust this means we agree that the TLS draft is lacking if its 
security considerations do not state this requirement?

> If the RBG of a
> system is broken, or controlled by the attacker, the security of the
> whole system should be assumed to be broken anyway.
> 

I agree that if the RBG is sabotaged, the whole system should be assumed 
broken. That is exactly why this covert channel is dangerous.

> I was a main author of the FIPS 203.
> 

Thank you for your efforts.

> Top level cryptographers know ML-KEM was not back-doored.
> 
Is "top level cryptographer" an official NIST designation or NIST 
certification?

More seriously, let us not argue over a claim I am not making. I called 
this a "backdoor accommodation" in my 2023 NIST comments, not a 
backdoor. The change and its consequences for security protocols need 
not be intentional. They can result from weighing the wrong risks or 
from ignoring historical attack vectors.

I expect that NIST is well aware of the reality of Dual_EC_DRBG and the 
damage caused by standardizing it.

Let us stick to the facts:

1. Kyber included a defense-in-depth step that hashed m and explicitly 
said "Do not send output of system RNG."

2. ML-KEM removed that step. As a result, if m is generated by a 
Dual_EC_DRBG-shaped kleptographic RBG, the ML-KEM ciphertext can carry a 
recoverable covert channel.

3. In TLS, a client can send an ML-KEM key share, receive a server 
ciphertext, and instrument its own decapsulation to recover the server's 
internal m.

4. If m were hashed before ML-KEM.Encaps_internal() as in Kyber, that 
Dual_EC_DRBG-shaped structure would be destroyed, and this specific 
oracle would be closed.

Do you dispute 1, 2, 3, or 4 as a matter of fact?

Kind regards,
Jacob Appelbaum

> Regards, Quynh.
> 
> From: Thom Wiggers <[email protected]> Sent: Wednesday, July 8,
> 2026 5:52 AM To: Eliot Lear <[email protected]> Cc: <[email protected]>
> <[email protected]> Subject: [EXTERNAL] [TLS] Re: WG Last Call: draft-
> ietf-tls-mlkem-08 (Ends 2026-07-08)
> 
> Hi,
> 
> ML-KEM is arguably not backdoorable unless you break the RNG. Bad
> RNG is something that we can't really protect against anyway.
> Classic cryptography is also broken if the RNG is busted. Finally,
> the TLS key schedule still mixes in all messages from both sides
> rendering the point moot for TLS.
> 
> On a more instructive point, ETSI's "quantum-safe enterprise
> transport security" (ETSI TS 104 145<https://www.etsi.org/deliver/
> etsi_ts/104100_104199/104145/01.01.01_60/ts_104145v010101p.pdf>,
> paragraph 5.3.2) relies exactly on generating the encapsulation seed
> deterministically instead of randomly sampling one. This mainly
> breaks forward secrecy, which is certainly bad. But hybrids or not
> are not relevant to this. In the classic approach they simply fixed
> the DH public key of the server, iirc. Friends don't let friends use
> ETS.
> 
> Cheers,
> 
> Thom
> 
> 
> Op 8 jul 2026, om 11:35 heeft Eliot Lear
> <[email protected]<mailto:[email protected]>> het volgende geschreven:
> 
> 
> 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.
> 
> 
> <OpenPGP_0x87B66B46D9D27A33.asc>_______________________________________________
>  TLS mailing list -- [email protected]<mailto:[email protected]> To
> unsubscribe send an email to [email protected]<mailto:tls-
> [email protected]>
> 
> 
> 
> _______________________________________________ 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]