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

["Dang, Quynh H. (Fed)" <[e-mail]>]

And NSA did not ask us to consider removing the hash.

Regards,
Quynh.

From: Dang, Quynh H. (Fed)
Sent: Wednesday, July 8, 2026 6:42 AM
To: TLS List <[e-mail]>
Cc: Markku-Juhani O. Saarinen <[e-mail]>
Subject: RE: [EXTERNAL] [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

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

The reason to remove it was that hashing m would be bad, introduce a cost for side-channel security implementations (ask Markku for detail).  In addition, we require an approved RBG. 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 was a main author of the FIPS 203.

Top level cryptographers know ML-KEM was not back-doored.

Regards,
Quynh.

From: Thom Wiggers <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 8, 2026 5:52 AM
To: Eliot Lear <[e-mail]<mailto:[e-mail]>>
Cc: <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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 -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>