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 <ietf-d...@dukhovni.org> 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 -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | sschm...@google.com
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
