El NIST tiene "definidas" 15 "curvas estándar", especificadas en FIPS 186- 4 . En realidad, ellos mismos no los definieron; los heredaron de SEC . Estas 15 curvas se agregan en 3 grupos:
- Las curvas P- * funcionan en un "campo principal" (las coordenadas del punto son enteros módulo a primo p ).
- Las curvas B- * funcionan en un "campo binario" (las coordenadas de los puntos son valores en GF (2 m ) ).
- Las curvas K- * funcionan en los mismos campos que las curvas B- *, pero tienen una estructura especial que permite cálculos más rápidos.
El NIST descubrió que había una gran renuencia a implementar el soporte para estas 15 curvas, y mucho menos para las curvas "generales", por una variedad de razones:
- Se considera que las matemáticas involucradas son "difíciles" (eso es más difícil de entender que RSA o Diffie-Hellman).
- ... más aún para curvas en campos binarios.
- Si bien es posible escribir un código "genérico" de manejo de curvas, el código que apunta a una curva específica a menudo es más fácil de implementar y más rápido. En particular, las curvas P- * funcionan con valores de módulo primo cuyo formato hace que la implementación sea más eficiente (reducción modular rápida).
- Ha habido reclamos recurrentes y de larga data de patentes , haciendo que el uso de la curva elíptica sea "arriesgado".
- ... especialmente para curvas en campos binarios;
- ... y más generalmente para curvas genéricas elegidas para tener alguna característica que sea beneficiosa para la implementación. No se sabe si una curva se puede patentar (a diferencia de una técnica de implementación respaldada por una estructura de curva especial), pero la incertidumbre ya produce una fuerte disuasión.
Por lo tanto, las personas desconfiaban de implementar un soporte genérico para curvas elípticas, porque parecía ser difícil, perjudicial para el rendimiento y un campo de minas legal. Pegarse a algunas de las curvas más simples parecía más fácil, más rápido y más seguro; y eso es lo que paso NIST (bueno, NSA) formalizó esta tendencia como su suite de criptografía " suite B ", que exige la implementación de exactamente dos curvas: P-256 y P-384.
En SSL / TLS y en X.509, se pueden usar curvas arbitrarias. Sin embargo, la mayoría de las implementaciones no admiten curvas arbitrarias. OpenSSL admite las 15 curvas NIST, pero no las curvas arbitrarias. Firefox solo admite P-256 y P-384; No estoy seguro de que el código de Microsoft (Windows, por lo tanto, Internet Explorer) acepte más que eso (quizás también el P-521). Si intenta utilizar cualquier otra curva que no sea P-256 o P-384, entonces encontrará problemas de interoperabilidad (más problemas de los que ya obtiene al utilizar curvas elípticas). Algunos escritores estándar, sintiendo que deben "ser prácticos", han admitido completamente este hecho y solo han prohibido el uso de otras curvas, como se puede ver en RFC 5480 .
La generación de su propia curva no es difícil, pero es sustancialmente más difícil que la generación de sus propios parámetros DH. Implica el conteo de puntos con algoritmo de Schoof o una variante del mismo. No podrá abarcar un generador de curvas en una hora y cien líneas de código Java, mientras que la producción de parámetros DH se puede hacer bajo estas restricciones. El costo computacional también es más alto (todavía obtendrá una buena curva en un minuto, pero no en 100 ms). Para ser breve, la gente no lo hace a menudo, o en absoluto.