I support moving forward with hybrids as a proactively safe deployment option. I think that supporting only Kyber for KEX is not enough. It would make sense to have more options.
Google uses NTRU HRSS internally: https://cloud.google.com/blog/products/identity-security/why-google-now-uses-post-quantum-cryptography-for-internal-comms If Google decides to use this externally, how easy would it be to get a codepoint for TLS ? On Tue, 7 Nov 2023 at 12:30, Scott Fluhrer (sfluhrer) <[email protected]> wrote: > > The problem with the argument “X trusts Kyber, so we don’t need hybrid” > (where X can be “NIST” or “the speaker”) is that trust, like beauty, is in > the eye of the beholder. Just because NIST (or any other third party) is > comfortable with just using Kyber (or Dilithium) does not mean that everyone > does. > > > > As long as there are a number of users that don’t quite trust fairly new > algorithms, there will be a valid demand for using those new algorithms with > older ones (which aren’t postquantum, but we are moderately confident that > are resistant to conventional cryptanalysis). > > > > From: TLS <[email protected]> On Behalf Of Watson Ladd > Sent: Monday, November 6, 2023 2:44 PM > To: Kris Kwiatkowski <[email protected]> > Cc: Bas Westerbaan <[email protected]>; TLS List > <[email protected]> > Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms? > > > > Why do we need FIPS hybrids? The argument for hybrids is that we don't trust > the code/algorithms that's new. FIPS certification supposedly removes that > concern so can just use the approved PQ implementation. > > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
