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]
