Migração pós-quântica em 2026: plano para desenvolvedores

Resposta curta. Em 2026, boa parte do trabalho pós-quântico na criptografia em trânsito se resolve com atualizações. O Chrome, o Firefox, as versões 26 dos sistemas da Apple, o OpenSSL 3.5, o Go 1.24+, o JDK 27 e o OpenSSH 10 negociam por padrão a troca de chaves híbrida com ML-KEM. Seu trabalho é encontrar as conexões que ainda não fazem isso: bibliotecas antigas, listas de grupos fixadas na configuração, middleboxes, TLS 1.2, VPNs, serviços internos. Assinaturas e certificados são a parte lenta. As CAs públicas ainda não podem emitir certificados ML-DSA para navegadores; por isso, faça o inventário agora, rode um piloto do ML-DSA na PKI privada e projete os sistemas pensando na agilidade de algoritmos. As datas de planejamento são as do rascunho do NIST, o IR 8547: chaves de 112 bits, como RSA-2048, descontinuadas após 2030, e todos os algoritmos de chave pública vulneráveis à computação quântica proibidos após 2035. A CNSA 2.0 da NSA define datas anteriores para os sistemas de segurança nacional dos EUA.

Dois problemas com dois relógios

Um computador quântico relevante para a criptografia quebraria o RSA, o Diffie-Hellman de campo finito e a criptografia de curvas elípticas (ECDH, ECDSA, EdDSA) com o algoritmo de Shor. A criptografia simétrica e os hashes sobrevivem com os tamanhos de chave atuais: AES-256 e SHA-256 ou maiores. Ninguém sabe dizer quando uma máquina assim vai existir. A página do projeto OpenSSH resume as estimativas publicadas como “de 5 a 20 anos, e muitos observadores esperam que cheguem em meados da década de 2030”. A migração se divide em dois problemas com urgências muito diferentes:

• Confidencialidade, que é urgente. O tráfego criptografado gravado hoje pode ser descriptografado quando o computador quântico existir. É a estratégia coletar agora, descriptografar depois (harvest now, decrypt later). Tudo o que precisa continuar secreto por mais de alguns anos já está exposto se a troca de chaves for clássica. A correção é a troca de chaves pós-quântica, e ela pode ser implantada hoje.
• Autenticação, que tem prazo. Uma assinatura falsificada só importa quando alguém confia nela, então o computador quântico precisa existir nesse momento. Mas as chaves de assinatura e as âncoras de confiança vivem muito tempo. Certificados raiz, chaves de firmware, chaves de assinatura de código e documentos assinados arquivados permanecem confiáveis por décadas, e substituí-los leva anos.

Planeje o trabalho nessa ordem: primeiro a troca de chaves, depois as assinaturas.

Os prazos que existem de fato

Três observações sobre esta tabela:

1. O IR 8547 ainda é um rascunho. As datas de 2030 e 2035 são as que órgãos governamentais e fornecedores usam para planejar, mas ainda não são política final do NIST. No rascunho, “descontinuado” (deprecated) significa que você ainda pode usar o algoritmo se aceitar o risco, e “proibido” (disallowed) significa que você não pode usá-lo de forma alguma.
2. O marco de 2030 atinge as chaves de 112 bits, sobretudo RSA-2048. O RSA-2048 ainda está em muitos certificados e em muitos signatários de tokens (dois dos seis endpoints da varredura abaixo o usam). P-256 e RSA-3072 têm 128 bits de segurança e continuam permitidos até 2035, mas migrar para eles rende no máximo cinco anos, porque o rascunho proíbe tudo o que é vulnerável à computação quântica após 2035.
3. A nota de rodapé da CNSA 2.0 importa para os híbridos. Os modos híbridos são permitidos, mas os algoritmos da CNSA 2.0 “se tornarão de seleção obrigatória na data indicada”, então uma configuração apenas clássica deixa de ser aceitável.

O que já é pós-quântico por padrão

Estes componentes negociam uma troca de chaves híbrida com ML-KEM sem nenhuma configuração, desde que as duas pontas sejam recentes o bastante:

O lado do servidor também avançou. Uma varredura feita com o OpenSSL 3.5.7 em 20 de outubro de 2026, com o script da seção de inventário, encontrou isto:

www.cloudflare.com:443     TLSv1.3  X25519MLKEM768    id-ecPublicKey 256 bit    ecdsa-with-SHA256
github.com:443             TLSv1.3  X25519,253bits    id-ecPublicKey 256 bit    ecdsa-with-SHA256
www.google.com:443         TLSv1.3  X25519MLKEM768    id-ecPublicKey 256 bit    ecdsa-with-SHA256
login.microsoftonline.com:443 TLSv1.3  ECDH,secp384r1    rsaEncryption 2048 bit    sha256WithRSAEncryption
api.stripe.com:443         TLSv1.3  X25519,253bits    rsaEncryption 2048 bit    sha256WithRSAEncryption
letsencrypt.org:443        TLSv1.3  X25519,253bits    id-ecPublicKey 256 bit    ecdsa-with-SHA384

Duas colunas contam a história. A troca de chaves é mista: alguns serviços têm o híbrido, outros não. As colunas do certificado são uniformemente clássicas, ECDSA P-256 ou RSA-2048. O mesmo vale para o SSH, em que o GitHub já escolhe o híbrido para um cliente OpenSSH 10:

debug1: kex: algorithm: mlkem768x25519-sha256

Passo 1: inventário

Não dá para migrar o que você não consegue listar. Um inventário criptográfico útil responde, para cada uso de criptografia de chave pública: qual algoritmo e tamanho de chave, qual biblioteca e versão, quem controla a configuração, por quanto tempo os dados protegidos precisam continuar confidenciais e por quanto tempo a chave ou a assinatura precisa continuar confiável.

Comece pelo que dá para medir de fora, seus endpoints TLS:

#!/bin/bash
for target in "$@"; do
  host=${target%:*}; port=${target##*:}; [ "$host" = "$target" ] && port=443
  out=$(openssl s_client -connect "$host:$port" -servername "$host" -brief </dev/null 2>&1)
  proto=$(grep -m1 "^Protocol version" <<<"$out" | cut -d: -f2 | xargs)
  group=$(grep -m1 "^Negotiated TLS1.3 group" <<<"$out" | cut -d: -f2 | xargs)
  [ -z "$group" ] && group=$(grep -m1 "^Peer Temp Key" <<<"$out" | cut -d: -f2 | cut -d, -f1-2 | tr -d ' ')
  cert=$(openssl s_client -connect "$host:$port" -servername "$host" </dev/null 2>/dev/null | openssl x509 -noout -text 2>/dev/null)
  key=$(grep -m1 "Public Key Algorithm" <<<"$cert" | cut -d: -f2 | xargs)
  bits=$(grep -m1 -o -E "\([0-9]+ bit\)" <<<"$cert" | tr -d '()')
  sig=$(grep -m1 "Signature Algorithm" <<<"$cert" | cut -d: -f2 | xargs)
  printf '%-26s %-8s %-17s %-25s %s\n' "$host:$port" "$proto" "$group" "$key $bits" "$sig"
done

O script precisa rodar com um cliente OpenSSL 3.5, porque clientes mais antigos nunca oferecem o híbrido, e para eles todo servidor parece clássico. Para muitos domínios de uma vez, o verificador de domínios em lote informa a troca de chaves, os algoritmos do certificado e a expiração de cada host.

Depois, olhe para dentro, onde está a maior parte do trabalho:

• Bibliotecas e runtimes. Liste as versões do OpenSSL, BoringSSL, Go, JDK, .NET, Node.js e Python em cada imagem e em cada host. O OpenSSL 3.0 já não tem suporte upstream e não tem ML-KEM, e o Ubuntu 24.04 ainda o distribui. Esse fato sozinho explica muitos resultados.
• Configuração explícita. Procure listas de grupos e de cifras como ssl_ecdh_curve, SSLOpenSSLConfCmd Groups, CurvePreferences, jdk.tls.namedGroups e KexAlgorithms. Cada uma delas é um ponto aonde a mudança de padrão trazida por uma atualização não chega.
• Código. Procure usos diretos das APIs de RSA, ECDSA, ECDH e Ed25519, tamanhos de chave, valores de alg de JWT e chaves públicas armazenadas em bancos de dados. Assinaturas armazenadas em formatos de dados são a parte mais difícil de mudar depois.
• Chaves e certificados de longa duração. Raízes de CAs privadas, chaves de assinatura de código e de firmware, assinatura de documentos, CAs de SSH, chaves mantidas em HSM. Anote a data de expiração de cada um e os algoritmos que o HSM aceita.
• Fornecedores. Balanceadores de carga, WAFs, proxies que inspecionam TLS, concentradores de VPN, bancos de dados gerenciados, APIs de SaaS. Peça a cada fornecedor, por escrito, o cronograma de ML-KEM e ML-DSA.

Registre o resultado em um formato legível por máquina. O CycloneDX criou o Cryptography Bill of Materials (CBOM) exatamente para isso. Ele descreve algoritmos, chaves, certificados e protocolos como componentes do inventário de software, ao lado do SBOM de pacotes que você talvez já gere.

Passo 2: conclua a troca de chaves

Para cada ponto de terminação TLS que você controla:

1. Atualize a biblioteca TLS. OpenSSL 3.5, Go 1.24 ou posterior, JDK 27, ou um build atual do BoringSSL ou do AWS-LC.
2. Remova as listas de grupos fixadas ou coloque X25519MLKEM768 em primeiro lugar nelas. Uma linha de hardening copiada de um guia antigo é o motivo mais comum para um servidor moderno negociar X25519 puro. Os detalhes do mecanismo estão em X25519MLKEM768 explicado.
3. Teste pelo caminho de rede real. O ClientHello híbrido tem cerca de 1,5 KB. Alguns firewalls, balanceadores de carga e proxies que inspecionam TLS falham com ClientHellos que ocupam dois pacotes. Compare um handshake híbrido e um apenas clássico pelo mesmo caminho antes de culpar o servidor.
4. Verifique os dois trechos. Atrás de uma CDN ou de um balanceador de carga, a conexão entre a borda e a origem é uma sessão TLS separada. O tráfego gravado nesse trecho pode ser coletado do mesmo jeito.
5. Aposente o TLS 1.2 onde for possível. Os grupos híbridos são definidos apenas para o TLS 1.3.

Depois, os canais fora da web:

• SSH. O OpenSSH 9.0 e posteriores já negociam um híbrido pós-quântico quando as duas pontas oferecem suporte. Servidores antigos, equipamentos de rede e implementações de SSH embarcadas muitas vezes não. Os clientes OpenSSH 10.1 e posteriores exibem um aviso que nomeia o risco: “This session may be vulnerable to ‘store now, decrypt later’ attacks.”
• VPNs e IPsec. O IKEv2 aceita trocas de chaves adicionais (RFC 9370), que os fornecedores usam para adicionar ML-KEM. Confira as notas de firmware do seu gateway.
• Criptografia na camada de aplicação. Tudo o que encapsula chaves de dados com RSA ou ECDH, como criptografia de envelope, backups criptografados ou mensagens de ponta a ponta, precisa de um caminho com ML-KEM ou com um KEM híbrido. O HPKE (RFC 9180) com um KEM híbrido é o bloco de construção habitual. O laboratório de HPKE mostra como as peças se encaixam.

Passo 3: assinaturas e certificados

Aqui o ecossistema ainda não está pronto para fazer o trabalho por você, então o trabalho em 2026 é de preparação:

• Certificados web públicos: espere, mas se prepare. Nenhum navegador aceita certificados ML-DSA de CAs públicas. O Chrome informou em fevereiro de 2026 que não tem plano imediato de adicionar certificados X.509 com chaves pós-quânticas ao seu root store. Ele está construindo um root store separado, resistente à computação quântica, baseado em Merkle Tree Certificates, que estão sendo padronizados no grupo de trabalho PLANTS da IETF. Até que isso chegue, o trabalho útil é a automação. Uma equipe capaz de rotacionar qualquer certificado em minutos vai trocar de algoritmo com facilidade, e as vidas úteis mais curtas dos certificados empurram na mesma direção.
• PKI privada: faça um piloto do ML-DSA agora. mTLS interno, service meshes, identidade de dispositivos e certificados de VPN estão sob seu controle nas duas pontas. O OpenSSL 3.5, o Go 1.27, o Java 24+, o .NET 10 e o BouncyCastle lidam com chaves e certificados ML-DSA. Conte com um certificado folha de cerca de 5,5 KB com ML-DSA-65 e teste o que quebra: tamanhos de buffer, limites de cabeçalho, suporte do HSM. O artigo ML-DSA na prática traz código funcional e as armadilhas dos formatos de chave.
• Âncoras de confiança de longa duração primeiro. Uma raiz ou uma chave de firmware criada em 2026 ainda vai ser considerada confiável depois de 2035. Para assinatura de firmware e de atualizações de software, a CNSA 2.0 exige os esquemas baseados em hash com estado LMS ou XMSS (SP 800-208) e espera uso exclusivo até 2030. O SLH-DSA, sem estado (FIPS 205), é a alternativa conservadora quando você não consegue gerenciar o estado das assinaturas.
• Artefatos assinados que precisam continuar verificáveis. Documentos, acervos e logs assinados hoje com ECDSA precisam ser protegidos de novo antes que as assinaturas deixem de ser confiáveis. Planeje a renovação dos carimbos do tempo e a reassinatura dos acervos, como a validação de longo prazo de PDFs já faz para certificados que expiram.
• Tokens e APIs. O JOSE e o COSE têm identificadores registrados para o ML-DSA (RFC 9964). Uma assinatura de 3,3 KB deixa um JWT com cerca de 4,5 KB em base64url, o que importa para cookies e cabeçalhos. Meça antes de mudar.

Passo 4: torne a próxima mudança barata

A migração não vai ser uma mudança única. A troca de chaves híbrida pode dar lugar, mais tarde, ao ML-KEM puro. O ML-DSA pode ganhar a companhia do FN-DSA, que o NIST planeja publicar como FIPS 206. As assinaturas compostas e híbridas ainda estão sendo projetadas. A agilidade criptográfica é o que impede que cada uma dessas mudanças vire outro projeto de vários anos:

• Os identificadores de algoritmo acompanham os dados (um OID, um alg do JOSE, um byte de versão), e os verificadores decidem com base neles em vez de presumir.
• Os tamanhos de chave e de assinatura não ficam fixos no código. Colunas, buffers e campos de protocolo têm espaço para kilobytes.
• As chaves são geradas, armazenadas e rotacionadas por automação. Nenhuma pessoa copia um arquivo PEM para uma configuração.
• A configuração fica em um único lugar por stack, então a próxima mudança de grupo ou de algoritmo é uma só edição.

Erros comuns

• Testar com um cliente antigo. O openssl s_client do OpenSSL 3.0, ou o curl compilado com ele, nunca oferece o híbrido. Aí todo servidor parece clássico, inclusive os que já migraram.
• Considerar a borda da CDN como a conexão inteira. O trecho entre o navegador e a borda muitas vezes é pós-quântico, enquanto o trecho entre a borda e a origem na mesma requisição não é.
• Desativar o híbrido para contornar um middlebox com defeito. Isso remove a proteção de todas as conexões. Corrija ou substitua o equipamento.
• Esperar os certificados ML-DSA públicos antes de fazer qualquer coisa. O inventário, as atualizações de bibliotecas e a automação de certificados vão ser necessários de qualquer forma, e levam mais tempo do que a espera.
• Tratar “descontinuado após 2030” como “permitido até 2035”. Os dados que você criptografar em 2029 com troca de chaves clássica ficam expostos durante todo o tempo em que precisam continuar confidenciais. Os prazos servem para a conformidade, não para a segurança.

Checklist para o restante de 2026

1. Faça uma varredura com o OpenSSL 3.5 de todos os endpoints TLS públicos e internos e registre o grupo, o algoritmo do certificado e a versão da biblioteca.
2. Atualize as bibliotecas TLS nas imagens base. Remova as listas de grupos fixadas. Faça a varredura de novo.
3. Teste o híbrido através de cada middlebox no caminho, incluindo o trecho entre a borda e a origem.
4. Atualize os servidores SSH para o OpenSSH 9.9 ou posterior para ter ML-KEM (o 9.0 e posteriores já oferecem o híbrido sntrup761), e os equipamentos de rede para os quais houver firmware.
5. Liste cada chave de assinatura e âncora de confiança de longa duração, com a data de expiração e os algoritmos que o HSM correspondente aceita.
6. Monte uma CA de teste com ML-DSA e emita certificados para um serviço interno.
7. Automatize a emissão e a rotação de certificados em todos os lugares onde elas ainda são manuais.
8. Peça aos fornecedores, por escrito, as datas de suporte a ML-KEM e ML-DSA.

Fontes

• NIST IR 8547 ipd, Transition to Post-Quantum Cryptography Standards (novembro de 2024), tabelas 2–4.
• NSA, Announcing the Commercial National Security Algorithm Suite 2.0 (CSA PP-22-1338, setembro de 2022): algoritmos e cronograma de transição.
• A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, EU PQC Workstream, versão 1.1, 11 de junho de 2025.
• NCSC, Timelines for migration to post-quantum cryptography (março de 2025).
• FIPS 203, FIPS 204, FIPS 205, SP 800-208.
• OpenSSH, Criptografia pós-quântica, e notas de versão do OpenSSH 9.0, 9.9, 10.0 e 10.1.
• OpenSSL, estratégia de versões (3.5 LTS até 2030-04-08). Notas de versão do Go 1.24, JEP 527.
• Google Security Blog, Cultivating a robust and efficient quantum-safe HTTPS (fevereiro de 2026).

As varreduras foram feitas em 20 de outubro de 2026 a partir de node:24.22.0-trixie (OpenSSL 3.5.7, OpenSSH 10.0p2).