[TLS] Re: [EXTERNAL] Re: Disallowing reuse of ephemeral keys

[Sophie Schmieg <[e-mail]>]

I strongly prefer 3.

In the ML-KEM spec, the consistency checks on the public keys are marked as
optional, so I think it would be a fair interpretation of FIPS 140-3 that
the required consistency checks consist of the optionally allowed empty set
in the case of ML-KEM.

On Mon, Jan 13, 2025 at 7:11 PM Viktor Dukhovni <[e-mail]>
wrote:

> On Mon, Dec 16, 2024 at 07:02:43AM -0800, Eric Rescorla wrote:
>
> > Thanks. It seems like that would imply that Web clients cannot safely
> > enforce a non-reuse requirement even if we had one.
> >
> > Do you plan to reuse ML-KEM keys as well?  The situation seems to be
> > different because, as Scott observes, it's the client who reaps the
> benefit.
>
> It may be worth noting that FIPS 140-3 requires pairwise consistency
> tests (PCTs) on generated (and imported) KEM keys before first use, with
> no exception carved out for single-use keys.  This factor of 2 or so
> performance hit[1] on single-use keys does create a temptation to amortise
> the cost by reusing the key a number of times (for a short time).
>
> Haven't taken any steps in that direction at this time.
>
> --
>     Viktor.
>
> [1]  Instead of keygen + decap, the single use cost becomes keygen +
>      encap + decap + decap.  Whether this is more or less than a 2x
>      performance hit depends on implementation details.
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
[e-mail]