Hi Viktor,
On 7/12/26 17:07, Viktor Dukhovni wrote:
On Sun, Jul 12, 2026 at 04:02:55PM +0200, David Stainton wrote:
There may be better designs but they will only slow down deployment.
The best course of action is restoring the hash over m.
The hash over "m" is not a matter for TLS to dictate.
The tls working group can easily make a statement in any draft related
to ML-KEM about it if it wants to achieve consensus.
It lives
inside the ML-KEM algorithm black box.
Large-scale adversaries love this kind of clean separation of concern
where the upper layer just accepts any issues with the lower layer. It
makes sense but it also means that it is a way to exploit different
assumptions at different layers.
Many TLS stacks that
are polymorphic over various KEMs don't even know which KEMs
are ML-KEM and which aren't. The X25519MLKEM768 hybrid isn't
ML-KEM, it is just another black box.
That isn't correct but it slightly depends on what you mean.
For example recovering `m` in the X25519MLKEM768 case is
straightforward. Noteworthy is that if the X25519 keypair is generated
after `m` is sampled, the adversary is able to predict the X25519
keypair. I trust that this is not in dispute.
Whether `m` comes directly from a compromised RNG, or from a whitened
RNG isn't something TLS can detect and has no effect on
interoperability.
That is why IETF endorsing the Kyber hashing strategy is a fine plan. No
one will notice except users of the covert channel and those worried
about ~300-1500 cycles.
Nothing productive, will happen in typical
implementations if TLS suggests whitening the RNG used with ML-KEM.
It closes the covert channel.
I for one have no intention to implement that.
With respect, that is your security posture, I think that is important
for people to know. Is there any evidence that would convince you to
change your mind, and if so, what is the standard of evidence that would
move you?
TLS is not supplying the
ML-KEM encapsulation step with its entropy, that's an internal detail of
the algorithm, and I don't expect to change that because of security
theatre motivated by this thread.
It depends on the implementation, of course. It isn't security theater
in any case. Some systems will be exploitable with this class of
attacks, and some will not. IETF should make the issues clear, and issue
clear guidance for people who want defense-in-depth.
Any language to that effect will I predict be broadly ignored.
The IETF doesn't have protocol police. We can survey your prediction
later. Currently, I see only a few implementations that hash `m` and I
suspect it will grow proportional to the humility of the developers in
question. The people designing their own RNG are probably going to feel
like that hash is a lot less important than people who can't
meaningfully inspect their rng or otherwise do anything but hope that
the cryptography actually protects us from _all_ the known possible
problems that might come along.
If someone wants to issue new code points, OIDs, ... test vectors,
for a new ML-KEM' that always hashes `m`, good luck with that...
Thankfully that isn't needed at all. There are other options but
restoring Kyber's hash is the easiest and fastest solution that closes
the covert channel.
Kind regards,
Jacob Appelbaum
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
