On Wed, Mar 29, 2023 at 02:59:51PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > Because that’s what CNSA requires.
I don't think that is the case. CNSA1 does not consider the Kyber part, and CNSA2 requires something that is not currently available. > > On Mar 29, 2023, at 00:45, Kampanakis, Panos <kpa...@amazon.com> wrote: > > > > > > > > > I would also like secp384r1_kyber1024 option, please. > > > > Why do you up the ECDH curve sec level with Kyber1024? It adds > > unnecessary size to the keyshare. like secp384r1_kyber768 > > combines two equivalent security levels. Is that the case? Secp384r1 is 192-level DH, but Kyber768 is quoted to be Category III (and I think it is not significantly above Category III requirements), which is defined as equivalent to 192-level encryption. 192-level DH is stronger than 192-bit encryption. (Another illustration of numbers not being comparable is that Category IV is defined as equivalent to 192-level hash.) I would pair secp384r1 with Kyber768 for completely different reasons: Kyber768 is what the team kyber recommends. > > From: TLS <tls-boun...@ietf.org> On Behalf Of Blumenthal, Uri - 0553 - MITLL > > Sent: Tuesday, March 28, 2023 10:40 PM > > To: Krzysztof Kwiatkowski <k...@amongbytes.com>; Christopher Wood > > <c...@heapingbits.net> > > Cc: TLS@ietf.org > > Subject: RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for > > draft-ietf-tls-hybrid-design > > > > Can we add secp256r1_kyber768 option for those who prefer NIST > > curves? > > > > I support this. > > > > I would also like secp384r1_kyber1024 option, please. > > > > Thanks I don't think there are very good reasons for NIST curves here outside wanting CNSA1 compliance, and for that you need secp384r1 classical part. And for that, I would pick secp384r1_kyber768. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
