Hay cuatro CSPs ECDSA P256 disponibles en Windows. ¿Cuál debo usar?

En una suite de cifrado como TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 , hay dos curvas involucradas:

• Uno se usa para la parte ECDHE: una clave Diffie-Hellman intercambiada se usa entre el cliente y el servidor, sobre una curva dada.
• El otro es para la firma ECDSA calculada por el servidor: el servidor firma su mensaje ServerKeyExchange . ECDSA es un algoritmo de firma que utiliza cálculos en una curva elíptica.

No hay ningún requisito de que ambas curvas sean iguales; En su mayoría no están relacionados y viven en mundos diferentes. A nivel conceptual, el que se usa para ECDHE es más importante, ya que debe garantizar la seguridad durante toda la vida útil de los datos que se intercambiarán a través del cable (es decir, si los datos siguen siendo importantes dentro de diez años, la curva aún debe sé robusto dentro de diez años); el que se usa en la firma es solo por ahora, y realmente no importa si se rompe mañana.

Tenga en cuenta que secreto hacia adelante tiene que ver con el intercambio de claves, es decir, la parte ECDHE. Esta es la misma idea: la seguridad del sistema de firmas solo importa por ahora. Por lo tanto, podría perfectamente tener un secreto hacia adelante impulsado por ECC con un conjunto de cifrado TLS_ECDHE_RSA_* , es decir, con una clave RSA en el certificado.

Normalmente, la opción de CSP (técnicamente, "proveedor de almacenamiento de claves CNG") es sobre el tipo de clave privada que se almacenará, es decir, que corresponde al certificado y la firma ECDSA (o RSA). La curva para ECDHE se elige de forma independiente (*), entre el cliente y el servidor, con secretos que se guardan solo en la RAM (y, por lo tanto, nunca se almacenan, que es el punto de confidencialidad).

Dicho esto, la única curva que se admite en todas partes es la curva P-256 de NIST, también conocida como "secp256r1" o "prime256r1" (no debe confundirse con "secp256k1", que es una curva distinta). La curva NIST P-384 también tiene una buena proporción de soporte generalizado, aunque tal vez no tanto como P-256. Además, el P-384 implica un poco más de trabajo computacional (aproximadamente tres veces más), lo que no importa en la práctica, excepto si están involucrados algunos sistemas integrados restringidos (no teléfonos inteligentes; realmente sistemas pequeños). Un punto adicional es que el P-256 ya garantiza una seguridad más que adecuada, incluso en lo que respecta a las mejoras tecnológicas: por lo que sabemos, si un intercambio de claves ECDHE P-256 se rompe alguna vez, será mediante el uso de un como sin embargo, la mítica computadora cuántica , y si tal bestia se construye alguna vez, entonces alcanzará la P-384 con casi la misma cantidad facilitar. En ese sentido, no hay ninguna ventaja de seguridad de usar P-384 en lugar de P-256.

Resumen: para una máxima interoperabilidad, use P-256. Las implementaciones SSL del cliente y del servidor todavía pueden decidir utilizar otra curva para la parte ECDHE; a menos que se aplique una guía específica, esa otra curva generalmente también será P-256 o (dependiendo de las implementaciones involucradas) Curve25519, que también es una buena opción para la seguridad.

^{(*) Mayormente. Algunas versiones de OpenSSL intentarán hacer coincidir el tamaño de la curva ECDHE con la curva utilizada en ECDSA, lo que puede tener sentido o no, ya que se relacionan con diferentes operaciones con diferentes características de seguridad, especialmente con respecto a futuras mejoras tecnológicas.}