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

[Peter C]

In ML-KEM, Bob derives b deterministically from m and H(ek).
If Bob tried to reuse b with a different public key, then the
re-encryption check would fail during decapsulation. 

Peter

> -----Original Message-----
> From: Viktor Dukhovni <ietf-d...@dukhovni.org>
> Sent: 10 March 2025 00:47
> To: tls@ietf.org
> Subject: [TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt
> 
> 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
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org