On Saturday, 1 April 2023 03:50:04 CEST, Krzysztof Kwiatkowski wrote:
I would pair secp384r1 with Kyber768 for completely different reasons:
Kyber768 is what the team kyber recommends.
Agreed.
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.
From my perspective, the two reasons for including a NIST curves are:
1. To have an option for those who require FIPS compliance. In
a short term at least one key agreement scheme should be
FIPS-approved. In the long term both of them should be
fips-approved. That way, in case security of Kyber768 falls
below 112-bits or simply implementation is broken, one can still
run key agreement in FIPS compliant manner. In the end, the
ultimate goal of hybrid-tls draft is to ensure that at least one
of the schemes provides security if the other gets broken. Would
be good to use this in FIPS context also.
2. NIST curves are more often implemented in HW than
Curve25519. When working with chips like ATECC608B, one ideally
only adds SW-based Kyber and can reuse existing HW-based ECDH.
Such migration is simpler, less risky and time-consuming than
adding SW-based X25519.
there's a third reason: the public CAs that support ECDSA almost
exclusively
support just P-256 and P-384, so if somebody implements ECDSA for the
public
internet, they have to support those two curves at the very least.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
