Re: EC curve preferences
On Fri, Nov 20, 2020 at 08:43:59AM -0800, Skip Carter wrote:
> I am sure this in the documentation somewhere; but where ?
>
> What are the preferred ECDH curves for a given keysize ? Which curves
> are considered obsolete/deprecated/untrustworthy ?
Is this a general question about industry best-practices or a question
about OpenSSL default or configurable behaviour? Or in other words,
is this a theory question or a how-to question?
Also, are you asking specifically about TLS, or more broadly (e.g. EC in
CMS).
For SSL, curve selection is controlled via the functions documented
under:
https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set1_groups.html
But this does not specify the default list, which is in ssl/t1_lib.c:
/* The default curves */
static const uint16_t eccurves_default[] = {
29, /* X25519 (29) */
23, /* secp256r1 (23) */
30, /* X448 (30) */
25, /* secp521r1 (25) */
24, /* secp384r1 (24) */
};
The full list of "available" curves is:
/*
* Table of curve information.
* Do not delete entries or reorder this array! It is used as a lookup
* table: the index of each entry is one less than the TLS curve id.
*/
static const TLS_GROUP_INFO nid_list[] = {
{NID_sect163k1, 80, TLS_CURVE_CHAR2}, /* sect163k1 (1) */
{NID_sect163r1, 80, TLS_CURVE_CHAR2}, /* sect163r1 (2) */
{NID_sect163r2, 80, TLS_CURVE_CHAR2}, /* sect163r2 (3) */
{NID_sect193r1, 80, TLS_CURVE_CHAR2}, /* sect193r1 (4) */
{NID_sect193r2, 80, TLS_CURVE_CHAR2}, /* sect193r2 (5) */
{NID_sect233k1, 112, TLS_CURVE_CHAR2}, /* sect233k1 (6) */
{NID_sect233r1, 112, TLS_CURVE_CHAR2}, /* sect233r1 (7) */
{NID_sect239k1, 112, TLS_CURVE_CHAR2}, /* sect239k1 (8) */
{NID_sect283k1, 128, TLS_CURVE_CHAR2}, /* sect283k1 (9) */
{NID_sect283r1, 128, TLS_CURVE_CHAR2}, /* sect283r1 (10) */
{NID_sect409k1, 192, TLS_CURVE_CHAR2}, /* sect409k1 (11) */
{NID_sect409r1, 192, TLS_CURVE_CHAR2}, /* sect409r1 (12) */
{NID_sect571k1, 256, TLS_CURVE_CHAR2}, /* sect571k1 (13) */
{NID_sect571r1, 256, TLS_CURVE_CHAR2}, /* sect571r1 (14) */
{NID_secp160k1, 80, TLS_CURVE_PRIME}, /* secp160k1 (15) */
{NID_secp160r1, 80, TLS_CURVE_PRIME}, /* secp160r1 (16) */
{NID_secp160r2, 80, TLS_CURVE_PRIME}, /* secp160r2 (17) */
{NID_secp192k1, 80, TLS_CURVE_PRIME}, /* secp192k1 (18) */
{NID_X9_62_prime192v1, 80, TLS_CURVE_PRIME}, /* secp192r1 (19) */
{NID_secp224k1, 112, TLS_CURVE_PRIME}, /* secp224k1 (20) */
{NID_secp224r1, 112, TLS_CURVE_PRIME}, /* secp224r1 (21) */
{NID_secp256k1, 128, TLS_CURVE_PRIME}, /* secp256k1 (22) */
{NID_X9_62_prime256v1, 128, TLS_CURVE_PRIME}, /* secp256r1 (23) */
{NID_secp384r1, 192, TLS_CURVE_PRIME}, /* secp384r1 (24) */
{NID_secp521r1, 256, TLS_CURVE_PRIME}, /* secp521r1 (25) */
{NID_brainpoolP256r1, 128, TLS_CURVE_PRIME}, /* brainpoolP256r1 (26) */
{NID_brainpoolP384r1, 192, TLS_CURVE_PRIME}, /* brainpoolP384r1 (27) */
{NID_brainpoolP512r1, 256, TLS_CURVE_PRIME}, /* brainpool512r1 (28) */
{EVP_PKEY_X25519, 128, TLS_CURVE_CUSTOM}, /* X25519 (29) */
{EVP_PKEY_X448, 224, TLS_CURVE_CUSTOM}, /* X448 (30) */
};
--
Viktor.
Re: EC curve preferences
Those "rigid curves" that will be used in the future - future how distant, and for how long? Regards, Uri > On Nov 20, 2020, at 13:54, Phillip Hallam-Baker wrote: > smime.p7s Description: S/MIME cryptographic signature
Re: EC curve preferences
There are currently two sets of preferred curves. CABForum approved use of the NIST curves from Suite B at 384 bits (and 521??) several years ago. Those are currently the only curves for which FIPS-140 certified HSMs are currently available and thus the only ones that can be supported by WebPKI CAs. The IRTF CFRG RG approved replacement curves based on rigid construction several years ago, These are intended to be the curves used in the future. In particular, these are the curves most likely to end up being supported in crypto co processors for CPUs. On Fri, Nov 20, 2020 at 11:44 AM Skip Carter wrote: > > I am sure this in the documentation somewhere; but where ? > > What are the preferred ECDH curves for a given keysize ? Which curves > are considered obsolete/deprecated/untrustworthy ? > > > -- > Dr Everett (Skip) Carter 0xF29BF36844FB7922 > s...@taygeta.com > > Taygeta Scientific Inc > 607 Charles Ave > Seaside CA 93955 > 831-641-0645 x103 > > >
RE: EC curve preferences
> From: openssl-users On Behalf Of Skip > Carter > Sent: Friday, 20 November, 2020 09:44 > > What are the preferred ECDH curves for a given keysize ? Which curves > are considered obsolete/deprecated/untrustworthy ? For TLSv1.3, this is easy. RFC 8446 B.3.1.4 only allows the following: secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), x25519(0x001D), x448(0x001E). Those are your choices. If you want interoperability, enable them all; if you want maximum security, only use X25519 and X448. See safecurves.cr.yp.to for the arguments in favor of the latter position. Frankly, unless you're dealing with something of very high value or that needs to resist breaking for a long time, I don't see any real-world risk in using the SEC 2 curves. You might want to disallow just secp256r1 if you're concerned about that key size becoming tractable under new attacks or quantum computing within your threat timeframe. Ultimately, this is a question for your threat model. For TLSv1.2, well... - Some people recommend avoiding non-prime curves (i.e. over binary fields, such as the sect* ones) for intellectual-property reasons. I'm not going to try to get into that, because IANAL and even if I were, I wouldn't touch that without a hefty retainer. - Current consensus, more or less, seems to be to use named curves and not custom ones. The arguments for that seem pretty persuasive to me. So don't use custom curves. - Beyond that? Well, here's one Stack Exchange response from Thomas Pornin (who knows a hell of a lot more about this stuff than I do) where he suggests using just prime256v1 (which is the same as secp256r1 I believe?) and secp384r1: https://security.stackexchange.com/questions/78621/which-elliptic-curve-should-i-use Those are the curves in Suite B, before the NSA decided to emit vague warnings about ECC. They subsequently decided P384 aka secp384r1 is OK until post-quantum primitives are standardized. So if your application prefers secp384r1 for TLSv1.2, then you can decide whether to also allow prime256v1 for interoperability. Again, that's a question for your threat model. All that said, some people will have different, and quite possibly better-informed, opinions on this. -- Michael Wojcik
