On Wed, Jul 8, 2026 at 4:21 PM Nico Williams <[email protected]> wrote:
> On Wed, Jul 08, 2026 at 10:06:07PM +0200, Tanja Lange wrote: > > In ECDH when you get aG from the server and compute the shared b(aG) you > don't > > learn anything about a. > > > > In ML-KEM the server encapsulates to your ephemeral public key starting > from > > some seed m. Decapsulating recovers the seed (and needs to, due to FO). > > > > In the scenario that the RNG is predictable there is no difference and an > > outside attacker gets the shared key in either scenario. Hashing the RNG > output > > before using it is at best a band aid. > > > > In the Dual-EC scenario there is a big difference because ML-KEM gives > you raw > > RNG output from the server any time you open a connection to it. > > Ah, ok, I get it now: the client gets a 32-byte RNG output from the > server during decapsulation. So it's a covert channel, but for active > participants, not for eavesdroppers, but it's real and dangerous. > Whitening the RNG output solves the problem. > There's a bit more to this story. Let's suppose your RNG is broken and observing a 32-byte output lets you recover the RNG state. And let's suppose that whitening mitigates this. First, hybrids *do not help here*. If you believe your ML-KEM implementation exposes a covert channel, the X25519MLKEM768 implementation calls into that same ML-KEM implementation and exposes that *same* covert channel. So this doesn't really have anything to do with this increasingly circuitous debate. Any concerns here would need to be reflected in both drafts. Now, you may well believe, yes, you should reflect it in both drafts... but whitening it *inside the ML-KEM implementation* still does not help. TLS is more than ML-KEM. It has a ServerHello random output. Why settle for the covert ML-KEM channel when there's an extremely obvious visible one? It sounds like folks are trying to classify RNG uses by whether they need whitening or not, but this does not make sense. Rather than whitening individual RNG uses one by one, the robust strategy is to whiten it in front of *every call to the RNG*. Trying to classify each one as needing or not needing whitening is a terrible risk management strategy. But once you do it in front of every call, you've actually just changed your RNG. You're using RNG' = Whiten(RNG()). And if you believe that only RNG' is secure... great, use RNG'. That outputs of your RNG are computationally independent of each other is such a basic security requirement for the deterministic part of your RNG (NIST calls the deterministic part a DRBG) that failing to meet it should be addressed in the DRBG itself. It's the same mitigation, just put in the right place. Fortunately, we have no shortage of tools with which to build secure DRBGs, because practically the entirety of symmetric cryptography is about transforming things into indistinguishable-from-random outputs in various forms. Two things can be true at the same time: 1. The security of your RNG is crucial to the security of TLS 2. The security of your RNG is not ML-KEM's responsibility (it's the RNG's responsibility) David
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
