¿Es el soporte de curva elíptica limitado en rhel / centos / redhat openssl suficientemente robusto?

6

Redhat finalmente se rindió después de insistir durante años en que las curvas elípticas tenían patentes y las deshabilitaron, y recientemente habilitó la friolera de tres algoritmos:

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

Pero una compilación de fuente directa de openssl 1.0.1i tiene docenas de curvas en comparación.

¿Es lo que redhat hizo lo suficientemente robusto? ¿Lo lisiaron?

    
pregunta ck_ 09.08.2014 - 15:13
fuente

1 respuesta

4

Voy a empezar. TL; DR: probablemente esté bien.

P-256 y P-384 parecen ser las "curvas" más ampliamente implementadas y / o preferidas, probablemente porque son las dos seleccionadas para enlace y el tamaño correcto para las fortalezas que actualmente se consideran cómodas y seguras. Para ser pedantes, en realidad son conjuntos de parámetros que consisten en una curva sobre un campo más un generador de un gran subgrupo, pero todos simplemente dicen curva por conveniencia; Los algoritmos como ECDSA y ECDH son los mismos para todas las curvas y claves, al igual que el algoritmo RSA es el mismo para todas las claves.

P-521 es la curva más grande actualmente estandarizada para SSL / TLS, que satisface a los maníacos del tamaño.

Es probable que el ECC menor de 160 bits se pueda romper bastante pronto, y los estándares importantes prohíben que menos de 224 o 256 sean cómodos; consulte enlace . Los campos binarios han demostrado ser menos populares. Por lo tanto, las curvas elegidas por RedHat son probablemente suficientes para una interoperabilidad decente.

Algunos, en particular Dan Bernstein, sostienen que TODAS las curvas estandarizadas NIST / SECG son difíciles de implementar sin canales laterales y que incluso podrían tener una puerta trasera, consulte enlace y enlace , pero las alternativas propuestas aún no están estandarizadas y, aparentemente, requerirán cambios en la implementación (de una forma de ecuación que retenga la resistencia del canal lateral) para que se desarrollen y desplieguen con suficiente amplitud antes de que se conviertan Útil, así que no busques eso mañana.

Pero si lo desea, creo que no debería haber ningún problema con el uso de su propia compilación completa, siempre que la versión OpenSSL ascendente sea lo suficientemente nueva como para contener las correcciones de seguridad necesarias, no es tan nueva, es incompatible con lo que su otro RedHat / CentOS paquetes esperan.

    
respondido por el dave_thompson_085 13.04.2017 - 14:48
fuente

Lea otras preguntas en las etiquetas