P-256 frente a P-384: cuándo compensa ECDSA de 192 bits

P-256 frente a P-384 es una elección entre dos curvas del NIST de la misma familia: los mismos algoritmos (ECDSA y ECDH), las mismas codificaciones, las mismas herramientas. P-384 eleva la seguridad clásica de unos 128 a unos 192 bits; P-256 es varias veces más rápida y la admite más hardware. En la mayoría de los sistemas, la decisión depende más de las políticas que del riesgo.

De un vistazo

Las velocidades se midieron en un núcleo de un Apple M4 Max con openssl speed; el script de tamaños de más abajo se ejecutó con OpenSSL 3.6.5.

¿Cuánta seguridad necesitas?

NIST SP 800-57 Part 1 sitúa las curvas de 256 a 383 bits en una seguridad de 128 bits y las de 384 a 511 bits en una de 192 bits. 128 bits quedan muy lejos de cualquier ataque clásico previsible: el mejor ataque conocido contra P-256 necesita del orden de 2¹²⁸ operaciones de grupo. El margen adicional de P-384 protege frente a avances criptoanalíticos inesperados sobre las curvas elípticas, no frente a la fuerza bruta, y no sirve de nada contra el algoritmo de Shor, que rompe ambas curvas con un esfuerzo similar. Por eso NIST IR 8547 (un borrador público inicial) las trata igual: ninguna queda obsoleta en 2030 (eso solo afecta a los algoritmos de 112 bits, como RSA-2048 y P-224), y ambas dejan de estar permitidas después de 2035.

Lo que de verdad decide son las políticas. La Commercial National Security Algorithm Suite original de la NSA (CNSA 1.0) exigía P-384 para ECDH y ECDSA, así que los productos para los sistemas de seguridad nacional de EE. UU. y sus cadenas de suministro la usan de forma predeterminada; CNSA 2.0 la sustituye por ML-KEM-1024 y ML-DSA-87. Las autoridades de certificación suelen elegir P-384 para las claves raíz e intermedias que deben seguir siendo fiables durante una década o más; ISRG Root X2 de Let's Encrypt y sus certificados intermedios ECDSA usan P-384, mientras que los certificados de los suscriptores pueden usar cualquiera de las dos curvas.

Coste en rendimiento y tamaño

OpenSSL incluye código ensamblador optimizado a mano para P-256, y por eso la diferencia es grande: unas 87.000 firmas P-256 por segundo frente a unas 9700 con P-384 en un núcleo de Apple M4 Max, y unas 29.000 frente a 4500 verificaciones. En un servidor TLS, la clave del certificado firma una vez por cada handshake completo, así que P-384 multiplica esa parte del coste del handshake por nueve, aproximadamente; para una autoridad de certificación que firma unos pocos certificados por segundo, es irrelevante.

Los tamaños crecen poco: las firmas, 32 bytes en bruto; las claves públicas, 32 bytes; los certificados, unos 60 bytes.

#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
printf 'hello' > msg
for curve in P-256 P-384; do
  openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:$curve -out key.pem 2>/dev/null
  openssl req -new -x509 -key key.pem -subj "/CN=example.com" -days 90 -outform DER -out cert.der 2>/dev/null
  openssl dgst -sha256 -sign key.pem -out sig.der msg
  printf '%s: SPKI %s bytes, DER signature %s bytes, self-signed certificate %s bytes\n' "$curve" \
    "$(openssl pkey -in key.pem -pubout -outform DER | wc -c | tr -d ' ')" \
    "$(wc -c < sig.der | tr -d ' ')" \
    "$(wc -c < cert.der | tr -d ' ')"
done
cd / && rm -rf "$dir"

P-256: SPKI 91 bytes, DER signature 71 bytes, self-signed certificate 388 bytes
P-384: SPKI 120 bytes, DER signature 102 bytes, self-signed certificate 451 bytes

Compatibilidad

Ambas curvas están en FIPS 186-5 y SP 800-186, en todas las bibliotecas TLS, en WebCrypto, en JOSE y COSE, en las tarjetas inteligentes PIV y en la lista de claves de certificado permitidas del CA/Browser Forum (P-256, P-384 y P-521). Las carencias están en el hardware seguro y en los autenticadores: el Secure Enclave de Apple solo ofrece P-256 para claves clásicas, las llaves de acceso usan ES256 de forma casi universal y algunos elementos seguros de IoT solo implementan P-256. Del lado del servidor, los HSM y los servicios KMS en la nube admiten ambas.

Cuándo elegir cada una

• Certificados TLS públicos: P-256. Es más rápida en los handshakes y se acepta en todas partes; los certificados hoja P-384 no aportan nada que un cliente pueda verificar.
• Claves de CA raíz e intermedias: P-384 es una opción habitual y razonable para claves de larga duración; puede firmar certificados hoja P-256.
• JWT y tokens de API: ES256, salvo que un perfil, como algunas especificaciones gubernamentales o financieras, exija ES384.
• Llaves de acceso y claves de dispositivos: P-256, porque es lo que ofrece el hardware.
• Sistemas CNSA 1.0 y sus proveedores: P-384 con SHA-384, y AES-256; planifica el paso a ML-KEM-1024 y ML-DSA-87 con CNSA 2.0.
• TLS poscuántico híbrido: X25519MLKEM768 para uso general; SecP384r1MLKEM1024 donde una política al estilo de CNSA exija curvas del NIST y parámetros de categoría 5.

Notas de migración

Cambiar de curva implica claves nuevas, pero las herramientas siguen siendo las mismas.

1. Genera la clave nueva con openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-384 (o P-256) dentro del HSM o del KMS donde vaya a residir.
2. Empareja bien el hash. P-384 se usa normalmente con SHA-384 (ES384, ecdsa-with-SHA384); ECDSA trunca los hashes más largos a la longitud del orden, pero las combinaciones desparejadas confunden las comprobaciones de políticas y a algunos verificadores.
3. Actualiza los identificadores: alg y crv de JOSE, el algoritmo de COSE, el esquema de firma de TLS y los perfiles de certificado. Durante la rotación, publica ambas claves en un JWKS con valores de kid distintos.
4. Ajusta el tamaño de los búferes fijos: las firmas en bruto pasan de 64 a 96 bytes, y las coordenadas, de 32 a 48 bytes.
5. Mide el rendimiento de los handshakes antes de pasar un endpoint TLS con mucho tráfico a un certificado P-384; la mayoría de los despliegues que adoptan P-384 por motivos de política mantienen P-256 donde esa política no se aplica.

Referencias

• NIST SP 800-186 (§3.2.1.3 P-256, §3.2.1.4 P-384)
• FIPS 186-5, estándar de firma digital
• NIST SP 800-57 Part 1 Rev. 5, tabla 2
• Borrador público inicial de NIST IR 8547
• RFC 7518 §3.4, ES256 y ES384
• Aviso de la NSA sobre los algoritmos de CNSA 2.0
• Baseline Requirements del CA/Browser Forum §6.1.5
• Cadenas de confianza de Let's Encrypt