[TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt

[Viktor Dukhovni <[e-mail]>]

On Sun, Mar 09, 2025 at 11:17:10PM -0000, D. J. Bernstein wrote:

> Viktor Dukhovni writes:
> > However, you'll be thrilled to learn that it is not possible for a TLS
> > server to reuse its ML-KEM keyshare when a client uses a fresh ephemeral
> > ML-KEM keyshare.
> 
> "Not possible"?
> 
> In ECDH, or more precisely ElGamal encrypton: Alice sends A = aG; Bob
> sends B = bG and C = bA+M; Alice recovers M as C-aB.
> 
> In Kyber, Alice sends G and A = aG+e; Bob sends B = Gb+d and C = Ab+M+c;
> Alice recovers M by rounding C-aB.
> 
> Bob can save time by reusing b. The speedup isn't as big as in the ECDH
> context if Alice chooses fresh G and A, but there's still _some_
> savings, notably the time to prepare b for multiplication.
> 
> I'm not saying that this is safe. I'm saying that it's what will happen
> if Bob is looking for the best speed that interoperates. It can also
> happen by accident, of course.

I'd expect such designs to be quite unlikely, because in constrast with
static DH keys, there is no notion of "ŷ" as a static ML-KEM key.  Also,
the APIs are not structured to support ŷ as an input to either
ML-KEM.Encaps(ek), or the derandomised ML-KEM.Encaps_internal(ek, 𝑚).

One might also hypothetically use a constant "𝑚", compromising the
derived shared key: (𝐾, 𝑟) ← G(𝑚 ‖ H(ek)).

I think the concern here is what "plasibly mainstream" implementations
are likely to do, where some reuse of client ephemeral keys can be
expected, but reuse of ŷ does not look particularly plausible.

-- 
    Viktor.