Os Padrões Pós-Quânticos do NIST Chegaram. Sua Infraestrutura Não Está Pronta.
Em agosto de 2024, o Instituto Nacional de Padrões e Tecnologia publicou três padrões finalizados de criptografia pós-quântica (PQC): FIPS 203 (ML-KEM, baseado em CRYSTALS-Kyber), FIPS 204 (ML-DSA, baseado em CRYSTALS-Dilithium) e FIPS 205 (SLH-DSA, baseado em SPHINCS+). Eles representam o ápice de um processo de padronização de oito anos iniciado em 2016. Os padrões existem. O modelo de ameaça é real. O que ainda não aconteceu é qualquer migração significativa da infraestrutura real da internet.
Os algoritmos criptográficos que protegem a maior parte da internet atual — RSA-2048, ECDH P-256, ECDSA — dependem de problemas matemáticos (fatoração de inteiros e logaritmo discreto) que computadores clássicos não conseguem resolver de forma eficiente. Um computador quântico criptograficamente relevante (CRQC) executando o algoritmo de Shor poderia quebrá-los em horas. Essa máquina não existe hoje, mas a ameaça de "colher agora, descriptografar depois" já está ativa: atores estatais estão coletando tráfego criptografado hoje com a intenção de descriptografá-lo quando o hardware quântico amadurecer.
O Que o NIST Realmente Padronizou
FIPS 203 / ML-KEM é o principal mecanismo de encapsulamento de chaves para criptografia geral e troca de chaves — a substituição direta do RSA e ECDH em protocolos como TLS. Ele oferece três conjuntos de parâmetros: ML-KEM-512, ML-KEM-768 e ML-KEM-1024, equilibrando o nível de segurança com o tamanho das chaves e textos cifrados. O ML-KEM-768 é considerado o padrão prático, oferecendo segurança comparável ao AES-192.
FIPS 204 / ML-DSA lida com assinaturas digitais, substituindo RSA e ECDSA em cadeias de certificados, assinatura de código e sistemas de autenticação. Assim como o ML-KEM, vem em três variantes de parâmetros (ML-DSA-44, ML-DSA-65, ML-DSA-87). O detalhe: as assinaturas ML-DSA são significativamente maiores que as assinaturas ECDSA — ML-DSA-65 produz assinaturas de 3.309 bytes contra 64–72 bytes do ECDSA. Isso tem implicações reais para o tamanho das cadeias de certificados nos handshakes TLS.
FIPS 205 / SLH-DSA é um esquema de assinatura baseado em hash sem estado, mais conservador em suas premissas de segurança do que o ML-DSA, pois depende apenas da segurança da função hash, e não de problemas de reticulados. É mais lento e produz assinaturas maiores, sendo mais adequado para assinaturas de longa duração em certificados raiz e firmware do que para autenticação de alto rendimento.
Onde a Internet Realmente Está Hoje
O suporte dos navegadores para troca de chaves híbrida chegou antes mesmo da finalização dos padrões. O Chrome ativou o X25519Kyber768 (um híbrido combinando ECDH clássico com Kyber) por padrão no Chrome 124 (abril de 2024). Cloudflare e Google executam PQC híbrido para TLS desde o final de 2023 em sua infraestrutura de borda. Mas isso cobre apenas a troca de chaves — as cadeias de certificados que validam a identidade do servidor ainda usam ECDSA ou RSA em toda a extensão.
O ecossistema de certificados está essencialmente não migrado. Os cerca de 200 milhões de certificados TLS ativos em meados de 2025 são esmagadoramente ECDSA ou RSA. Autoridades certificadoras, incluindo DigiCert e Let's Encrypt, começaram a testar a emissão de certificados PQC, mas ainda não lançaram certificados PQC de produção em escala. O problema se agrava: certificados PQC com assinaturas ML-DSA aumentariam substancialmente o tamanho dos handshakes TLS, potencialmente quebrando clientes com limites rígidos de tamanho de pacote ou afetando o desempenho em conexões de alta latência.
Os protocolos VPN também estão atrasados. As implementações de WireGuard, OpenVPN e IPsec/IKEv2 variam amplamente no suporte a PQC. O OpenSSH adicionou suporte para a troca de chaves híbrida sntrup761x25519-sha512 na versão 8.5 (2021) e a tornou padrão na 9.0 (2022), tornando-se uma das integrações PQC mais amplamente implantadas. Mas produtos VPN usados em ambientes corporativos — Cisco, Palo Alto, Fortinet — têm cronogramas variados, com muitos ainda planejando suporte PQC para 2026–2027.
O Cronograma que as Organizações Enfrentam
O cronograma do governo dos EUA é o mais prescritivo. O Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) da NSA determina a migração PQC para sistemas de segurança nacional, com prazos diferentes por tipo de sistema. Assinatura de software e firmware: até 2025. Equipamentos de rede: até 2026. Sistemas operacionais: até 2027. A maioria dos sistemas governamentais classificados e sensíveis: até 2033. A própria orientação do NIST na Publicação Especial 1800-38B fornece um roteiro de migração para agências federais com cronogramas semelhantes.
Para organizações privadas, ainda não há mandato regulatório — mas isso está mudando. A diretiva NIS2 da UE inclui requisitos de agilidade criptográfica, e a ENISA (Agência da UE para Cibersegurança) publicou diretrizes de migração PQC recomendando que as organizações concluam as fases de inventário e planejamento até 2025 e iniciem a migração ativa até 2026. Reguladores do setor financeiro no Reino Unido e na UE emitiram orientações semelhantes.
A janela de "colher agora, descriptografar depois" é o motor crítico para priorização. Qualquer dado com requisito de confidencialidade além de 5 a 10 anos deve ser tratado como já em risco se estiver sendo transmitido hoje com criptografia clássica. Registros de saúde, acordos financeiros, propriedade intelectual e comunicações classificadas se enquadram nessa categoria.
Os Desafios Técnicos que a Migração Realmente Envolve
A migração PQC não é uma simples substituição direta. Os tamanhos maiores de chaves e assinaturas nos algoritmos pós-quânticos criam problemas de compatibilidade em cascata. As chaves públicas do ML-KEM-768 têm 1.184 bytes, comparadas a 32 bytes do X25519. As chaves públicas do ML-DSA-65 têm 1.952 bytes. Protocolos com cabeçalhos de tamanho fixo, módulos de segurança de hardware com limites de tamanho de chave e firmware de HSM anterior ao PQC exigem atualizações ou substituição.
As bibliotecas criptográficas estão à frente da maioria dos aplicativos. O OpenSSL 3.x suporta PQC através do provedor Open Quantum Safe (OQS). O BoringSSL (usado pelo Chrome e Android) integrou o Kyber. A biblioteca liboqs validada pelo NIST fornece implementações de referência. Mas integrá-las em sistemas de produção exige testes de regressão de desempenho, especialmente em sistemas embarcados e dispositivos IoT restritos, onde a sobrecarga computacional do ML-KEM pode ser significativa.
A infraestrutura de autoridade certificadora precisa de atualizações substanciais. Emitir certificados PQC exige atualizar o software da CA, HSMs capazes de operações ML-DSA, respondedores OCSP e pontos de distribuição de CRL. Toda a cadeia PKI — CAs raiz, CAs intermediárias, certificados folha — precisa migrar de forma coordenada, mantendo a compatibilidade reversa durante um período de transição que pode durar uma década.
O que as Organizações Precisam Fazer Agora
Realize um inventário criptográfico. Mapeie todo sistema, serviço e fluxo de dados que usa criptografia de chave pública. Isso inclui endpoints TLS, VPNs, infraestrutura SSH, pipelines de assinatura de código, sistemas PKI, bancos de dados criptografados e quaisquer HSMs ou cartões inteligentes. A NIST SP 1800-38B fornece uma metodologia detalhada para esse processo de inventário.
Priorize pela sensibilidade e longevidade dos dados. Sistemas que transmitem ou armazenam dados que exigem confidencialidade além de 2030 devem estar no topo da fila de migração. Ataques de colher agora e descriptografar depois tornam a ameaça real hoje, mesmo que o computador quântico ainda não exista.
Ative a criptografia híbrida onde disponível. Modos híbridos (clássico + PQC) fornecem resistência quântica sem sacrificar a segurança clássica caso o algoritmo PQC apresente vulnerabilidades. A RFC 9370 da IETF padroniza a troca de chaves híbrida para TLS 1.3. A maioria das bibliotecas TLS modernas suporta o modo híbrido X25519MLKEM768 hoje.
Atualize as dependências de bibliotecas criptográficas. Atualize para OpenSSL 3.3+, builds do BoringSSL datados após janeiro de 2024, ou equivalente com suporte ao provedor OQS. Audite qualquer código criptográfico incorporado ou aceleração de hardware que possa ter suposições de algoritmos clássicos fixas.
Engaje sua autoridade certificadora e fornecedores de PKI. Pergunte à DigiCert, Sectigo, Let's Encrypt e operadores de CA internos sobre seus roteiros de migração PQC e compromissos de cronograma. Incorpore essas datas em seus próprios horizontes de planejamento.
Planeje testes de desempenho. Os algoritmos PQC não são uniformemente mais lentos, mas são diferentes. ML-KEM é rápido em software; assinaturas baseadas em hash como SLH-DSA são lentas. Avalie suas cargas de trabalho específicas — especialmente aquelas que fazem altos volumes de verificação de assinatura, como CDN, balanceador de carga ou serviço de autenticação em escala.
A ameaça quântica não é iminente no sentido de "um CRQC existirá no ano que vem". Estimativas confiáveis da IBM, Google e pesquisadores acadêmicos colocam a computação quântica criptograficamente relevante a pelo menos 10 a 15 anos de distância, nas trajetórias atuais. Mas as migrações criptográficas levam de 5 a 15 anos para serem concluídas em infraestruturas complexas. O NIST publicou os padrões. O relógio da migração começou. As organizações que iniciarem o planejamento sistemático e a migração precoce agora evitarão correrias em modo de crise quando os prazos regulatórios chegarem — ou quando um avanço na computação quântica alterar o cronograma.