Is the limited elliptic curve support in rhel/centos/redhat openssl robust enough?

Question

Redhat finally gave in after insisting for years that elliptic curves had patents and disabling them, recently enabling a whopping three algorithms:

CentOS 6.5
openssl ecparam -list_curves                            
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field 

CentOS 7.0
openssl ecparam -list_curves                      
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field

But a direct source build of openssl 1.0.1i has dozens of curves in comparison.

Is what redhat did robust enough? Did they cripple it?

Answer 1

I'll start. TL;DR: It's probably OK.

P-256 and P-384 seem to be the most widely implemented and/or preferred "curves", probably because they are the two selected for http://en.wikipedia.org/wiki/NSA_Suite_B and the right size for strengths currently considered comfortably safe. To be pedantic they are really parameter sets consisting of a curve over a field plus a generator of a large subgroup, but everyone just says curve for convenience; the algorithms such as ECDSA and ECDH are the same for all curves and keys, just as the algorithm RSA is the same for all keys.

P-521 is the largest curve currently standardized for SSL/TLS, which satisfies size maniacs.

ECC smaller than 160 bits is probably breakable fairly soon, and important standards prohibit less than 224 or 256 to be comfortable; see http://www.keylength.com . Binary fields have proven less popular. Thus the curves RedHat chose are likely enough for decent interoperability.

Some, notably Dan Bernstein, argue that ALL the standardized NIST/SECG curves are hard to implement without sidechannels and could even be backdoored, see http://safecurves.cr.yp.to and https://crypto.stackexchange.com/questions/12898/is-there-a-feasible-method-by-which-nist-ecc-curves-over-prime-fields-could-be-rigged , but the proposed alternatives aren't yet standardized and will apparently require changes in implementation (of an equation form that retains the sidechannel resistance) to be developed and deployed widely enough before they become useful, so don't look for that tomorrow.

But if you want, I think there should be nothing wrong with using your own completist build, as long as the upstream OpenSSL version new enough to contain needed security fixes isn't so new it's incompatible with what your other RedHat/CentOS packages expect.