ML-DSA vs ECDSA: a migração pós-quântica das assinaturas

ML-DSA vs ECDSA é a metade da transição pós-quântica que diz respeito às assinaturas. O ECDSA com a P-256 gera assinaturas de 64 bytes e está em toda parte, mas o algoritmo de Shor o quebra. O ML-DSA (FIPS 204, agosto de 2024) resiste aos ataques quânticos conhecidos e é rápido, mas as chaves e as assinaturas dele ocupam kilobytes. Ao contrário da troca de chaves, em que o ML-KEM híbrido já é o padrão nos navegadores, a migração das assinaturas ainda está, em grande parte, por fazer.

Visão geral

As velocidades foram medidas com openssl speed em um núcleo de um Apple M4 Max. O ML-DSA do OpenSSL é escrito em C portátil; implementações otimizadas assinam várias vezes mais rápido.

Por que a mudança é necessária

O ECDSA se baseia no problema do logaritmo discreto em curvas elípticas, que o algoritmo de Shor resolve de forma eficiente em um computador quântico grande e tolerante a falhas. Essa máquina ainda não existe, e as estimativas de quando ela poderá existir variam muito, mas as assinaturas têm uma propriedade que define a urgência delas: falsificar uma assinatura no futuro não desfaz uma autenticação passada. Um handshake TLS autenticado com ECDSA em 2026 não pode ser atacado retroativamente, como podem ser as trocas de chaves gravadas. O que precisa de atenção desde cedo é tudo cujas assinaturas devem continuar confiáveis por muitos anos: chaves de CAs raiz e de CAs intermediárias, firmware e cadeias de inicialização, raízes de assinatura de código, documentos jurídicos e arquivamento de longo prazo.

O ML-DSA é uma assinatura baseada em reticulados (derivada do CRYSTALS-Dilithium) cuja segurança se apoia nos problemas Module-LWE e Module-SIS, e não se conhece contra ela nenhuma aceleração quântica além das genéricas. O NIST IR 8547 (um rascunho público inicial) propõe deixar de permitir o ECDSA, o EdDSA e o RSA após 2035, e a CNSA 2.0 da NSA exige o ML-DSA-87 para sistemas de segurança nacional, começando pela assinatura de software e de firmware.

O problema do tamanho

O tamanho é o que torna a migração difícil. Um servidor TLS se autentica com uma cadeia de certificados e uma assinatura no handshake; com ECDSA, as chaves do certificado folha e do intermediário, as assinaturas deles, dois SCTs embutidos e a assinatura do CertificateVerify somam algumas centenas de bytes. Com o ML-DSA-44, os mesmos elementos chegam a cerca de 14,7 KB (duas chaves públicas de 1.312 bytes mais cinco assinaturas de 2.420 bytes: duas nos certificados, duas nos SCTs e a do CertificateVerify), e ainda mais com o ML-DSA-65. Isso faz a primeira leva de mensagens do servidor ultrapassar a janela de congestionamento inicial do TCP, o que acrescenta idas e voltas na rede, e pressiona os limites antiamplificação do QUIC.

#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
for alg in EC ML-DSA-44 ML-DSA-65; do
  if [ "$alg" = EC ]; then
    openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out key.pem 2>/dev/null
    label="ECDSA P-256"
  else
    openssl genpkey -algorithm "$alg" -out key.pem 2>/dev/null
    label="$alg"
  fi
  openssl req -new -x509 -key key.pem -subj "/CN=example.com" -days 90 -outform DER -out cert.der 2>/dev/null
  printf '%-12s certificate %5s bytes\n' "$label" "$(wc -c < cert.der | tr -d ' ')"
done
cd / && rm -rf "$dir"

ECDSA P-256  certificate   388 bytes
ML-DSA-44    certificate  3985 bytes
ML-DSA-65    certificate  5514 bytes

A resposta da Web PKI ainda está sendo projetada. Em fevereiro de 2026, o Chrome anunciou que pretende se apoiar nos Merkle Tree Certificates (certificados de árvore de Merkle, um Internet-Draft do grupo PLANTS da IETF), que substituem a maior parte das assinaturas de cada certificado por provas de inclusão curtas, e que não pretende adicionar certificados X.509 pós-quânticos ao root store atual dele. O CA/Browser Forum ainda não aprovou o ML-DSA para certificados TLS de confiança pública. PKIs privadas já podem emitir certificados ML-DSA conforme a RFC 9881, e o OpenSSL 3.5 e versões posteriores, o Bouncy Castle e outras bibliotecas oferecem suporte a eles.

Opções híbridas e compostas

Durante a transição, muitas implantações querem assinaturas que sejam verificadas tanto por clientes antigos quanto por novos, ou que continuem seguras se qualquer um dos algoritmos falhar:

• Assinaturas compostas (draft-ietf-lamps-pq-composite-sigs, ainda um Internet-Draft) definem um único identificador de algoritmo para cada combinação, como ML-DSA-65 com ECDSA P-256, cuja assinatura só é válida se as duas partes forem verificadas. A RFC 9980 do OpenPGP segue a mesma abordagem com ML-DSA-65+Ed25519, e o OpenSSH 10.4 adicionou um tipo de chave experimental ML-DSA-44+Ed25519.
• Assinaturas duplas anexam duas assinaturas independentes (o CMS aceita várias estruturas SignerInfo; alguns formatos de documento permitem vários campos de assinatura), e cada verificador confere a que entende.
• PKIs paralelas emitem certificados clássicos e pós-quânticos e deixam os clientes escolherem, o que corresponde ao modelo que a negociação do TLS já permite por meio de signature_algorithms.

Quando escolher cada um

• Certificados de servidor TLS públicos, chaves de acesso, OIDC e JWTs públicos: ECDSA (ou Ed25519) por enquanto; acompanhe o trabalho dos navegadores e da IETF para saber quando migrar.
• PKI privada para serviços e dispositivos de longa duração: ML-DSA-65, ou ML-DSA composto com ECDSA onde existirem os dois tipos de verificadores.
• Firmware e inicialização segura (secure boot): ML-DSA-87 ou os esquemas baseados em hash LMS, XMSS ou SLH-DSA, dependendo de você precisar ou não de conformidade com a CNSA 2.0.
• Assinatura de código e de pacotes: adicione o ML-DSA ao lado das assinaturas existentes à medida que os ecossistemas (Sigstore, fabricantes de sistemas operacionais) passarem a oferecer suporte.
• Blockchains: a escolha não cabe a você; existem propostas de assinaturas pós-quânticas para várias blockchains, mas nenhuma está implantada de forma ampla no Bitcoin ou no Ethereum.
• Tokens e sessões de curta duração: o ECDSA continua adequado até os verificadores migrarem, já que o risco de falsificação só existe durante a vida útil do token ou da sessão.

Notas de migração

1. Faça o inventário de todas as chaves de assinatura e de todos os verificadores (uma lista de materiais criptográficos ajuda), com o tempo de vida das chaves e quem as verifica.
2. Elimine suposições sobre tamanho: colunas de banco de dados, limites de cabeçalhos HTTP (uma assinatura ML-DSA-65 tem cerca de 4,4 KB em base64), armazenamento em cartões inteligentes, códigos QR e registros DNS.
3. Torne os algoritmos negociáveis: identificadores de algoritmo nos formatos, listas de algoritmos permitidos nos verificadores e IDs de chave para que chaves novas possam ser introduzidas ao lado das antigas.
4. Comece pelas raízes de longa duração: crie desde já CAs raiz e intermediárias ML-DSA ou compostas para PKIs privadas, já que as raízes levam anos para serem distribuídas.
5. Teste o desempenho em caminhos reais: latência do handshake com cadeias maiores, vazão de assinaturas (uma ordem de grandeza menor que a do ECDSA em código portátil), verificação em dispositivos com recursos limitados.
6. Acompanhe a situação do FIPS e das políticas: o FIPS 204 é final, o NIST IR 8547 ainda é um rascunho, as assinaturas compostas ainda são rascunhos e as regras da Web PKI ainda não mudaram.

Referências

• FIPS 204, padrão de assinatura digital baseado em reticulados de módulo
• FIPS 186-5, padrão de assinatura digital
• RFC 9881, ML-DSA em X.509
• Rascunho público inicial do NIST IR 8547
• draft-ietf-lamps-pq-composite-sigs (Internet-Draft)
• draft-ietf-plants-merkle-tree-certs (Internet-Draft)
• Programas raiz do Chrome, incluindo o programa resistente à computação quântica
• Perguntas frequentes da NSA sobre a CNSA 2.0