P-256 vs P-384: quando o ECDSA de 192 bits vale a pena

P-256 vs P-384 é uma escolha entre duas curvas do NIST da mesma família: os mesmos algoritmos (ECDSA e ECDH), as mesmas codificações, as mesmas ferramentas. A P-384 eleva a segurança clássica de cerca de 128 para cerca de 192 bits; a P-256 é várias vezes mais rápida e tem suporte em mais hardware. Para a maioria dos sistemas, a decisão depende mais de política do que de risco.

Visão geral

As velocidades foram medidas em um núcleo de um Apple M4 Max com openssl speed; o script de tamanhos abaixo foi executado com o OpenSSL 3.6.5.

De quanta segurança você precisa?

A NIST SP 800-57 Parte 1 coloca as curvas de 256 a 383 bits no nível de segurança de 128 bits e as de 384 a 511 bits no de 192 bits. Os 128 bits já estão muito além de qualquer ataque clássico previsível: o melhor ataque conhecido contra a P-256 exige da ordem de 2¹²⁸ operações no grupo. A margem extra da P-384 protege contra avanços inesperados da criptoanálise de curvas elípticas, não contra a força bruta, e em nada ajuda contra o algoritmo de Shor, que quebra as duas curvas com esforço semelhante. Por isso, o NIST IR 8547 (um rascunho público inicial) trata as duas da mesma forma: nenhuma delas se torna obsoleta em 2030 (isso vale apenas para algoritmos de 112 bits, como RSA-2048 e P-224), e as duas deixam de ser permitidas após 2035.

O que realmente pesa é a política. A Commercial National Security Algorithm Suite original da NSA (CNSA 1.0) exigia a P-384 para ECDH e ECDSA, e por isso os produtos para sistemas de segurança nacional dos EUA e as cadeias de fornecimento deles usam essa curva por padrão; a CNSA 2.0 a substitui pelo ML-KEM-1024 e pelo ML-DSA-87. As autoridades certificadoras costumam escolher a P-384 para chaves raiz e intermediárias que precisam continuar confiáveis por uma década ou mais; a ISRG Root X2 da Let’s Encrypt e os intermediários ECDSA dela usam a P-384, enquanto os certificados finais emitidos para os clientes podem usar qualquer uma das duas curvas.

Custo de desempenho e de tamanho

O OpenSSL traz código assembly otimizado à mão para a P-256, e é por isso que a diferença é grande: cerca de 87.000 assinaturas P-256 por segundo contra cerca de 9.700 da P-384 em um núcleo do Apple M4 Max, e cerca de 29.000 contra 4.500 verificações. Em um servidor TLS, a chave do certificado assina uma vez por handshake completo, então a P-384 multiplica essa parte do custo do handshake por cerca de nove; para uma autoridade certificadora que assina alguns certificados por segundo, isso é irrelevante.

Os tamanhos crescem de forma modesta: 32 bytes a mais nas assinaturas em formato bruto, 32 bytes nas chaves públicas e cerca de 60 bytes nos certificados.

#!/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

Suporte

As duas curvas estão no FIPS 186-5 e na SP 800-186, em todas as bibliotecas TLS, na WebCrypto, no JOSE e no COSE, nos cartões inteligentes PIV e na lista de chaves de certificado permitidas pelo CA/Browser Forum (P-256, P-384 e P-521). As lacunas estão no hardware seguro e nos autenticadores: o Secure Enclave da Apple oferece apenas a P-256 para chaves clássicas, as chaves de acesso usam ES256 quase universalmente e alguns elementos seguros de IoT implementam apenas a P-256. No lado do servidor, os HSMs e os serviços de KMS na nuvem oferecem suporte às duas.

Quando escolher cada uma

• Certificados TLS públicos: P-256. Ela é mais rápida nos handshakes e aceita em toda parte; certificados folha P-384 não trazem nenhum ganho que um cliente possa verificar.
• Chaves de CAs raiz e intermediárias: a P-384 é uma escolha comum e razoável para chaves de longa duração; ela pode assinar certificados folha P-256.
• JWTs e tokens de API: ES256, a menos que um perfil, como algumas especificações governamentais ou financeiras, exija ES384.
• Chaves de acesso e chaves de dispositivos: P-256, porque é o que o hardware oferece.
• Sistemas CNSA 1.0 e os fornecedores deles: P-384 com SHA-384, e AES-256; planeje a migração para ML-KEM-1024 e ML-DSA-87 da CNSA 2.0.
• TLS pós-quântico híbrido: X25519MLKEM768 para uso geral; SecP384r1MLKEM1024 onde uma política no estilo da CNSA exigir curvas do NIST e parâmetros de categoria 5.

Notas de migração

Trocar de curva significa gerar chaves novas, mas as ferramentas continuam as mesmas.

1. Gere a nova chave com openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-384 (ou P-256) dentro do HSM ou do KMS em que ela vai ficar.
2. Combine o hash corretamente. A P-384 normalmente é usada com SHA-384 (ES384, ecdsa-with-SHA384); o ECDSA trunca hashes mais longos para o comprimento da ordem do grupo, mas pares incompatíveis confundem verificações de política e alguns verificadores.
3. Atualize os identificadores: alg e crv do JOSE, o algoritmo COSE, o esquema de assinatura do TLS e os perfis de certificado. Durante a rotação, publique as duas chaves em um JWKS com valores de kid diferentes.
4. Redimensione buffers fixos: as assinaturas em formato bruto passam de 64 para 96 bytes, e as coordenadas, de 32 para 48 bytes.
5. Faça benchmarks dos handshakes antes de trocar o certificado de um endpoint TLS movimentado por um P-384; a maioria das implantações que adotam a P-384 por razões de política mantém a P-256 onde a política não se aplica.

Referências

• NIST SP 800-186 (§3.2.1.3 P-256, §3.2.1.4 P-384)
• FIPS 186-5, padrão de assinatura digital
• NIST SP 800-57 Parte 1 Rev. 5, Tabela 2
• Rascunho público inicial do NIST IR 8547
• RFC 7518 §3.4, ES256 e ES384
• Aviso da NSA sobre os algoritmos da CNSA 2.0
• Baseline Requirements do CA/Browser Forum, §6.1.5
• Cadeias de confiança da Let’s Encrypt