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.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
