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 <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
