Criptografia Pós-Quântica Não É Mais Teórica: Seu Roadmap de Migração
Em agosto de 2024, o NIST publicou os primeiros padrões de criptografia pós-quântica finalizados de sua história: FIPS 203 (ML-KEM, baseado em CRYSTALS-Kyber), FIPS 204 (ML-DSA, baseado em CRYSTALS-Dilithium) e FIPS 205 (SLH-DSA, baseado em SPHINCS+). Esses padrões encerram um processo de padronização de vários anos que envolveu competição criptográfica global, revisão pública e múltiplas rodadas de criptoanálise. A criptografia pós-quântica não é mais um problema de pesquisa — é um problema de engenharia e migração.
Por que a Urgência É Real Agora, Não em 10 Anos
A narrativa comum sobre criptografia pós-quântica sugere que a migração pode esperar até que os computadores quânticos sejam poderosos o suficiente para quebrar RSA e criptografia de curva elíptica — capacidade que a maioria das estimativas coloca entre 10 e 20 anos. Essa narrativa é perigosamente equivocada, e o motivo é um modelo de ameaça chamado "harvest now, decrypt later" (HNDL).
Atores estatais e ameaças sofisticadas já estão coletando tráfego de rede criptografado hoje. Sessões TLS, túneis VPN, e-mails criptografados e chamadas de API sensíveis estão sendo gravados e armazenados. Os dados criptografados são ininteligíveis hoje, mas se um computador quântico suficientemente potente se tornar disponível em 2035 ou 2040, esse tráfego armazenado poderá ser descriptografado retroativamente.
Isso significa que dados criptografados hoje com RSA-2048 ou ECDH P-256 — se ainda precisarem ser secretos daqui a 15 anos — já estão efetivamente comprometidos do ponto de vista da confidencialidade de longo prazo. Comunicações governamentais, dados de segurança nacional, históricos de transações financeiras, registros de saúde e contratos de longa duração se enquadram nessa categoria. Para organizações com requisitos longos de classificação de dados, o relógio da migração começou a correr anos atrás.
O que os Padrões NIST Realmente Especificam
Os três padrões finalizados abrangem diferentes funções criptográficas:
FIPS 203 / ML-KEM (anteriormente CRYSTALS-Kyber) é um mecanismo de encapsulamento de chave — o substituto resistente a quantum para troca de chaves RSA e Diffie-Hellman em protocolos como TLS. Baseia-se na dificuldade do problema Module Learning With Errors, uma estrutura matemática baseada em reticulados (lattice) considerada resistente a ataques clássicos e quânticos. O ML-KEM possui três conjuntos de parâmetros: ML-KEM-512 (segurança comparável ao AES-128), ML-KEM-768 (comparável ao AES-192) e ML-KEM-1024 (comparável ao AES-256).
FIPS 204 / ML-DSA (anteriormente CRYSTALS-Dilithium) é um esquema de assinatura digital — o substituto para assinaturas ECDSA e RSA usadas em code signing, autoridades certificadoras, assinatura de e-mails e tokens de autenticação. Também baseado em reticulados, oferece segurança robusta com tamanhos de chave e assinatura relativamente compactos.
FIPS 205 / SLH-DSA (anteriormente SPHINCS+) é um esquema de assinatura baseado em hash. Assinaturas baseadas em hash têm um histórico mais longo de escrutínio criptoanalítico do que os esquemas baseados em reticulados, tornando o SLH-DSA uma opção conservadora de backup para organizações que desejam diversidade em suas fundações criptográficas. A desvantagem são tamanhos de assinatura maiores.
O NIST também está padronizando o FALCON (agora FN-DSA) como um quarto esquema de assinatura otimizado para ambientes restritos. Ele oferece assinaturas menores que o ML-DSA, mas com requisitos de implementação mais complexos.
A Complexidade de Migração que a Maioria das Organizações Está Subestimando
Migração criptográfica parece uma troca de bibliotecas — substituir os algoritmos antigos pelos novos — mas na prática é mais próxima de uma auditoria de infraestrutura que leva anos. A criptografia está incorporada em todas as camadas do stack de uma organização: cadeias de certificados TLS, chaves de host SSH, pipelines de code signing, módulos de segurança de hardware (HSMs), assinatura de firmware, criptografia de e-mail S/MIME, protocolos VPN, chaves de assinatura JWT, criptografia de banco de dados, criptografia de backup e muito mais.
Muitos desses sistemas não expõem opções de configuração fáceis para trocar famílias de algoritmos. HSMs exigem atualizações de firmware ou substituição de hardware para suportar novos algoritmos. Autoridades certificadoras e infraestrutura PKI precisam ser reconstruídas ou atualizadas. Fornecedores e parceiros upstream e downstream precisam suportar os mesmos algoritmos para que a autenticação mútua funcione. Sistemas de controle industrial, dispositivos embarcados e hardware IoT com vida útil operacional de 10 a 15 anos podem nunca receber firmware resistente a quantum.
O princípio de crypto-agility — projetar sistemas para trocar primitivas criptográficas sem alterações arquiteturais — é a resposta certa para sistemas novos, mas a maioria das organizações trabalha com sistemas construídos sem ele. Retrofit de crypto-agility exige o mesmo trabalho de descoberta e inventário que a própria migração.
Esquemas Híbridos: A Ponte Prática
A IETF e as principais implementações de TLS convergiram para a troca de chaves híbrida como estratégia de migração para TLS: combinar um algoritmo clássico (ECDH) com um algoritmo pós-quântico (ML-KEM) em um único handshake, de modo que a sessão seja protegida enquanto qualquer um dos algoritmos for seguro. Essa abordagem protege tanto contra fraquezas não descobertas nos novos algoritmos pós-quânticos quanto contra ataques "harvest now, decrypt later" usando computadores quânticos.
O Google testa troca de chaves híbrida no Chrome desde 2023 usando uma combinação de X25519 e ML-KEM-768, designada X25519MLKEM768. A Cloudflare já a implantou em sua rede de borda. As versões mais recentes do BoringSSL, OpenSSL 3.x (via provedor OQS) e LibreSSL suportam esquemas híbridos. Para TLS, o caminho de migração é razoavelmente claro e as ferramentas estão amadurecendo rapidamente.
Para esquemas de assinatura, a migração é mais lenta porque os certificados precisam ser reemitidos por CAs confiáveis. O CA/Browser Forum (CA/B Forum) está trabalhando em padrões para certificados pós-quânticos, mas a implantação em massa de certificados assinados com PQ provavelmente levará de 3 a 5 anos até obter suporte amplo em navegadores e trust stores de sistemas operacionais.
Seu Framework de Priorização de Migração
Nem tudo precisa migrar ao mesmo tempo. Uma abordagem baseada em risco prioriza com base em duas dimensões: o quão sensíveis são os dados e por quanto tempo eles precisam permanecer confidenciais.
Comece pela troca de chaves no TLS voltado para o exterior: esta é a maior exposição a HNDL, as ferramentas estão disponíveis hoje, e os esquemas híbridos significam que você não precisa abandonar algoritmos clássicos. Atualizar para uma biblioteca TLS com suporte a ML-KEM e habilitar troca de chaves híbrida em seus load balancers e API gateways é acionável no curto prazo.
Em seguida, faça um inventário de sua infraestrutura PKI e de certificados. Identifique todas as autoridades certificadoras — internas e externas — e suas configurações de algoritmo. Planeje a complexidade operacional de executar PKI paralela (clássica e pós-quântica) durante o período de transição, já que nem todos os clientes suportarão certificados PQ imediatamente.
Avalie sua frota de HSMs. A maioria dos HSMs fabricados antes de 2022 não suporta ML-KEM ou ML-DSA nativamente. Fornecedores de HSM como Thales, Entrust e Utimaco publicaram roadmaps de PQC, mas os ciclos de substituição de hardware são longos e as aprovações de orçamento são lentas. Inicie essas conversas de procurement agora.
Segredos de longa duração são o alvo de migração de maior prioridade. Chaves de criptografia que protegem dados arquivados, chaves privadas de CA raiz, credenciais VPN de longo prazo e chaves de code signing que autenticam software por períodos de vários anos precisam urgentemente de proteção resistente a quantum. Backups criptografados com RSA de 2024 ainda serão recuperáveis por um adversário quântico em 2040.
O que Implementar Neste Trimestre
Habilite a troca de chaves híbrida em TLS para endpoints externos — tanto no lado do servidor (nginx, HAProxy, Cloudflare, AWS ALB) quanto no lado do cliente, onde você controla o stack TLS. Teste a compatibilidade com sua base de clientes existente antes de implementar amplamente. Execute um inventário de todos os ativos criptográficos usando ferramentas como Venafi ou o PKI secrets engine do HashiCorp Vault. Engaje seu fornecedor de HSM sobre o timeline de PQC deles. Avalie se algum dado que você criptografa hoje tem um requisito de confidencialidade que se estenda além de 2035. Informe seu CISO ou liderança de segurança com uma avaliação de risco por escrito que quantifique a exposição a HNDL — a maioria dos orçamentos de segurança responde mais rápido a enquadramentos de risco concretos do que a argumentos abstratos sobre timelines.
A criptografia pós-quântica não é um problema que se resolve esperando. Os padrões estão finalizados, as ferramentas existem para os casos de uso de maior prioridade, e a ameaça "harvest now, decrypt later" é real e contínua. Organizações que iniciarem seu inventário de migração agora terão anos de margem para executar metodicamente. Aquelas que esperarem até que computadores quânticos ameacem visivelmente os sistemas de produção estarão executando sob condições de emergência.