Viktor Dukhivni wrote:
>Guidance to encourage fresh keys every ~5 minutes and every ~10 users is not
>unreasonable.
I don't think time is the important factor. The important thing is that
encapsulation keys used with different servers are independent. If you have a
timing side channel in KEM.Decaps(dk, c) that leaks the encapsulation key, this
encapsulation key should not enable passive eavesdropping of connections with
other servers. Timing side channels leaking private keys has been common for
classical algorithms and are likely also for quantum-resistant KEMs.
ML-KEM KeyGen() is so fast that reusing encapsulation keys to save a few CPU
cycles is not justifiable.
Cheers,
John
From: Viktor Dukhovni <ietf-d...@dukhovni.org>
Date: Sunday, 9 March 2025 at 15:43
To: tls@ietf.org <tls@ietf.org>
Subject: [TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt
On Sun, Mar 09, 2025 at 02:02:55PM +0000, John Mattsson wrote:
> Viktor Dukhivni wrote:
> >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.
>
> Yes, that solves half the problem, but I would also like my servers to
> not talk to clients reusing key shares with other servers.
I've seen no evidence that TLS client implementations exist or are being
planned that will use *long-term* ML-KEM keys to generate keyshares.
Any occasional short-term reuse is much less riskly in ML-KEM than it
would be in ECDH. If ML-KEM is secure enough to use at all, it should
be secure enough for some short-term key reuse.
I very much expect that there will not be separate code points for or a
prohibition against key reuse, and nevertheless key reuse will be
infrequent and at most short-term to amortise initial keygen most, with
most of the benefit gained in the first O(10) users, and rapidly
diminishing gains thereafter.
The behaviour of mainstream implementations will not stay secret, and
nobody will want to be seen as negligent of best practice. The guidance
should be that single-use is recommended, but otherwise reuse should be
rather limited both in temporal duration and use count. Guidance to
encourage fresh keys every ~5 minutes and every ~10 users is not
unreasonable.
And if some day we learn that quantum computers are impossible, we'll go
back to just X25519, or if CRQCs arrive, we'll stop using hybrids and
will use whichever pure PQ algorithms are preferred at that time.
--
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
