> > Ultimately, I want fewer choices, but the direction the discussion is > headed seems about right. At least in the short term, I think we need to > eschew compression and only include one offer.
I also prefer fewer choices initially. The only reason we're testing both X25519+Kyber512 and X25519+Kyber768 is that there is a possibility that Kyber768 becomes the default [1] and because of its size, X25519+Kyber768 causes fragmentation in some cases where X25519+Kyber512 doesn't. * (2) to be able to declare security of generated keys in FIPS-mode for > _both_ - classical and post-quantum schemes (once Kyber is > standardized).— Why is this required? NIST writes Current NIST standards, which were not necessarily designed to provide post-quantum security, can accommodate several hybrid key establishment constructions in “FIPS mode,” as defined in FIPS 140. For example, assume that the value Z is a shared secret that was generated within a NIST-approved cryptographic scheme, and that a value T is generated or distributed through other scheme(s), which could be the output of a key encapsulation method (KEM). The following are the different ways to incorporate the value T in the key derivation procedure to achieve a hybrid mode which is permitted by current standards: [...] Here they're speaking about adding non-FIPS PQ to a non-PQ FIPS kex,[2] but the other way around is also ok — what am I missing? Best, Bas [1] Not expressing an opinion on whether that's good or not. [2] https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs On Thu, Aug 18, 2022 at 1:05 AM Martin Thomson <m...@lowentropy.net> wrote: > On Sat, Aug 13, 2022, at 04:13, Scott Fluhrer (sfluhrer) wrote: > > Well, if we were to discuss some suggested hybrids (and we now know the > > NIST selection), I would suggest these possibilities: > > > > - X25519 + Kyber512 > > - P256 + Kyber512 > > - X448 + Kyber768 > > - P384 + Kyber768 > > Any specific pairs of primitives should be specified in a different > document to this one. > > Ultimately, I want fewer choices, but the direction the discussion is > headed seems about right. At least in the short term, I think we need to > eschew compression and only include one offer. Partly because I think that > there might be better options available to us than compression, partly > because compression will be annoying to implement correctly, and partly > because we're still in the phase where this is being trialed. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
