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. It lives
inside the ML-KEM algorithm black box. 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.
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. Nothing productive, will happen in typical
implementations if TLS suggests whitening the RNG used with ML-KEM.
I for one have no intention to implement that. 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.
Any language to that effect will I predict be broadly ignored.
If someone wants to issue new code points, OIDs, ... test vectors,
for a new ML-KEM' that always hashes `m`, good luck with that...
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
