Os Padrões de Criptografia Pós-Quântica do NIST São Definitivos — Confira o Cronograma de Migração que Toda Organização Precisa Conhecer

Os Padrões São Definitivos. O Relógio Está Correndo.

Em agosto de 2024, o National Institute of Standards and Technology (NIST) publicou o FIPS 203, o FIPS 204 e o FIPS 205 — os primeiros padrões finalizados de criptografia pós-quântica (PQC) da história. Após quase uma década de avaliação, a agência padronizou três algoritmos: ML-KEM (Module Lattice Key Encapsulation Mechanism, baseado no Kyber), ML-DSA (Module Lattice Digital Signature Algorithm, baseado no Dilithium) e SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, baseado no SPHINCS+). Um quarto algoritmo, o FN-DSA (baseado no Falcon), deve ser padronizado em uma publicação FIPS subsequente. Não se trata de propostas ou rascunhos. São padrões, e a orientação do NIST é clara: comece a migração agora.

A urgência não está no que os computadores quânticos conseguem fazer em 2026 — está no que serão capazes de fazer entre 2030 e 2035, e no que adversários já estão fazendo hoje. O modelo de ameaça harvest-now-decrypt-later significa que agentes estatais e atacantes bem financiados estão capturando tráfego criptografado agora, armazenando-o e apostando que um computador quântico criptograficamente relevante (CRQC) eventualmente irá quebrá-lo. Qualquer dado que precise permanecer confidencial por mais de cinco a dez anos já está em risco. Isso inclui registros de saúde, contratos financeiros, comunicações governamentais e propriedade intelectual.

O que os Computadores Quânticos Podem Realmente Quebrar — e Quando

Os computadores quânticos de hoje são máquinas ruidosas e de pequena escala. O processador Heron da IBM e sistemas semelhantes operam na faixa de centenas a poucos milhares de qubits físicos — muito abaixo dos milhões de qubits lógicos com correção de erros necessários para executar o algoritmo de Shor contra RSA-2048 ou ECDSA P-256. As máquinas atuais não conseguem quebrar nenhum sistema criptográfico em produção. A estimativa realista para um CRQC capaz de quebrar RSA-2048 é entre 2030 e 2035, com algumas projeções otimistas situando esse prazo antes, caso os avanços em correção de erros ocorram mais rapidamente do que o esperado.

O que o algoritmo de Shor quebra: RSA (todos os tamanhos de chave em uso prático), troca de chaves Diffie-Hellman (incluindo variantes de campo finito e curva elíptica) e assinaturas ECDSA/EdDSA. O que ele não quebra: cifras simétricas como AES-256, que exigem apenas dobrar o tamanho da chave (o algoritmo de Grover oferece apenas uma aceleração quadrática). O TLS 1.3, como implantado hoje, depende de ECDHE para troca de chaves e ECDSA ou RSA para autenticação de certificados — ambos são vulneráveis a longo prazo. SHA-256 e SHA-3 são considerados resistentes a ataques quânticos nos tamanhos de saída atuais, com uma modesta redução na margem de segurança.

Os Três Novos Algoritmos: Detalhes Técnicos

ML-KEM (FIPS 203 / Kyber) é o padrão principal para encapsulamento de chaves — o mecanismo usado para estabelecer segredos compartilhados em protocolos como TLS. Ele opera sobre problemas de redes modulares (especificamente o problema Module Learning With Errors). No conjunto de parâmetros ML-KEM-768 (aproximadamente 128 bits de segurança quântica), as chaves públicas têm 1.184 bytes e os textos cifrados têm 1.088 bytes — maiores do que a chave pública de 256 bytes do RSA-2048, mas o desempenho é impressionante: ML-KEM-768 alcança aproximadamente 15.000–20.000 encapsulamentos por segundo em um núcleo de servidor moderno, em comparação com aproximadamente 3.000–5.000 operações RSA-2048 por segundo para geração de chaves. O desencapsulamento é igualmente rápido. A geração de chaves no ML-KEM é dramaticamente mais rápida do que no RSA.

ML-DSA (FIPS 204 / Dilithium) é o padrão principal para assinaturas digitais. No ML-DSA-65 (aproximadamente 128 bits de segurança quântica), os tamanhos de assinatura são de 3.293 bytes e as chaves públicas têm 1.952 bytes. A taxa de assinatura chega a aproximadamente 5.000–8.000 assinaturas por segundo por núcleo, com a verificação sendo ainda mais rápida. Em comparação, o ECDSA P-256 assina a aproximadamente 20.000–40.000 operações por segundo — o ML-DSA é mais lento, mas a diferença é administrável para a maioria das aplicações. Os tamanhos maiores de assinatura são o principal desafio de integração, especialmente para cadeias de certificados e ambientes com restrições de recursos.

SLH-DSA (FIPS 205 / SPHINCS+) é um esquema de assinatura baseado em hash que oferece uma base de segurança conservadora e bem compreendida. Ele depende apenas da segurança da função hash subjacente (SHA-256 ou SHAKE), não de suposições sobre dureza de redes. A contrapartida é o desempenho e o tamanho: SLH-DSA-128s produz assinaturas de 7.856 bytes e assina a aproximadamente 100–500 operações por segundo, dependendo do conjunto de parâmetros. É mais adequado para casos de uso de alta garantia — assinatura de firmware, autoridades certificadoras raiz ou qualquer contexto em que a assinatura seja pouco frequente e o tamanho da assinatura seja aceitável.

Troca de Chaves Híbrida: A Ponte Segura

Como os novos algoritmos são menos testados em batalha do que RSA e ECDH — que têm décadas de criptoanálise no mundo real — o caminho de migração recomendado é a troca de chaves híbrida: combinar um algoritmo clássico com um pós-quântico, de modo que a segurança se mantenha enquanto qualquer um deles permanecer intacto. O IETF RFC 9180 (HPKE) e os rascunhos de padrões para troca de chaves híbrida PQC no TLS 1.3 definem mecanismos concretos. O Google Chrome já habilitou por padrão a troca de chaves híbrida X25519+ML-KEM-768 a partir do Chrome 131 (final de 2024). Cloudflare, AWS e Azure estão implantando ou já implantaram PQC híbrido em sua infraestrutura de terminação TLS. O overhead de desempenho ao adicionar ML-KEM a um handshake TLS existente é de aproximadamente 1–2 milissegundos de latência adicional e cerca de 2 KB de dados extras no handshake — insignificante para a maioria das aplicações.

Cronograma de Migração por Porte da Organização

Grandes empresas e infraestrutura crítica (2024–2027): Inicie o inventário criptográfico agora. Identifique todos os sistemas que usam RSA, ECDSA, ECDH e Diffie-Hellman. Priorize segredos de longa duração e repositórios de dados de alta sensibilidade. Implante TLS híbrido com ML-KEM nos serviços voltados para a internet. Atualize os pipelines de emissão de certificados para suportar ML-DSA. Trabalhe com fornecedores quanto aos prazos de suporte para firmware e HSM. O NIST recomenda que grandes organizações concluam a migração principal até 2030.

Organizações de médio porte (2025–2028): Aproveite o suporte PQC dos provedores de nuvem (AWS Certificate Manager, Google Cloud e Azure estão adicionando opções de certificados PQC). Habilite PQC híbrido em load balancers e API gateways à medida que as opções de configuração forem disponibilizadas. Atualize soluções de VPN e acesso remoto — muitos fornecedores (Cisco, Palo Alto, Fortinet) já anunciaram ou lançaram suporte a PQC.

Pequenas organizações (2026–2030): Siga seus fornecedores de software e nuvem. Atualize as bibliotecas TLS (OpenSSL 3.x, BoringSSL e liboqs já suportam ML-KEM e ML-DSA). Migre as autoridades certificadoras quando sua CA suportar FIPS 203/204. A maior parte do trabalho virá com as atualizações de ferramentas padrão.

Checklist de Migração

• Inventário: Catalogue todas as dependências criptográficas — certificados TLS, chaves SSH, certificados de assinatura de código, configurações de VPN, dados criptografados em repouso e chaves armazenadas em HSM.
• Priorize pelo tempo de vida dos dados: Qualquer segredo que precise permanecer confidencial após 2030 precisa de proteção hoje contra ataques harvest-now-decrypt-later.
• Habilite TLS híbrido: Implante X25519+ML-KEM-768 em todos os endpoints TLS 1.3. A maioria dos principais fornecedores de CDN e load balancer já suporta isso ou terá suporte nos lançamentos de 2025.
• Atualize as cadeias de certificados: Planeje a migração para certificados ML-DSA. Monitore o roadmap da sua CA e teste em ambiente de staging com liboqs ou builds do OpenSSL habilitados para OQS.
• Audite os pipelines de assinatura de código: Substitua a assinatura baseada em ECDSA por ML-DSA ou SLH-DSA para firmware, imagens de container e pacotes de software.
• Avalie HSM e gerenciamento de chaves: Confirme se o seu fornecedor de HSM suporta FIPS 203/204/205. Thales, Entrust e AWS CloudHSM já publicaram roadmaps de PQC.
• Atualize o SSH: OpenSSH 9.0+ suporta troca de chaves ML-KEM híbrida. Habilite-o para a infraestrutura de acesso privilegiado.
• Teste o desempenho no seu ambiente: Execute benchmarks de ML-KEM e ML-DSA com liboqs antes de se comprometer com a escolha dos conjuntos de parâmetros.
• Treine sua equipe: Os engenheiros de segurança precisam entender as suposições da criptografia baseada em redes em nível conceitual para avaliar as afirmações dos fornecedores e a qualidade das implementações.
• Defina um prazo firme: O NIST recomenda descontinuar RSA e ECC para estabelecimento de chaves e assinaturas até 2030. Incorpore essa data no seu roadmap de segurança agora.

A transição pós-quântica é a maior migração de infraestrutura criptográfica desde a mudança de SSL para TLS — e tem um prazo mais rígido. Os algoritmos estão finalizados, as implementações estão amadurecendo, e os navegadores e provedores de nuvem já estão em movimento. A única variável é se a sua organização vai migrar no próprio cronograma ou se verá forçada a correr quando a ameaça se tornar urgente.