On Sun, Mar 09, 2025 at 03:16:46PM +0000, John Mattsson wrote:
> 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 that leak the secret key in under ~10 samples would
be newsworthy. I would support a broad recommendation (SHOULD) of
single-use keys, but not MUST, nor extreme measures such as separate
code points.
> 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.
Sure, fast enough that we can expect typical mainstream implementations
to employ single-use ephemeral keys. But, "not justifiable" is a stretch
without an opportunity to consider the particulars of the case in
question.
--
Viktor.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
