Padrões de criptografia pós-quântica do NIST estão finalizados — seu relógio de migração está correndo

O NIST finalizou três padrões de criptografia pós-quântica em agosto de 2024: ML-KEM (FIPS 203, baseado em CRYSTALS-Kyber), ML-DSA (FIPS 204, baseado em CRYSTALS-Dilithium) e SLH-DSA (FIPS 205, baseado em SPHINCS+). Após uma década de avaliação e múltiplas rodadas de algoritmos, eles estão prontos para produção. O relógio da migração começou no dia em que os padrões foram publicados — não no dia em que os computadores quânticos chegarem.

O cronograma prático não é abstrato. O governo dos EUA determinou que as agências federais iniciem a migração para PQC até 2030 para a maioria dos sistemas, com a infraestrutura classificada se movendo mais cedo. A indústria já está à frente: o Google Chrome enviou ML-KEM híbrido em TLS em 2023 e desde então foi atualizado para a versão final FIPS 203. A Apple adicionou PQC ao iMessage com iOS 17.4. O Signal atualizou seu protocolo em 2024. Se você opera infraestrutura que deve permanecer segura por 10 anos ou mais — especialmente qualquer coisa envolvendo troca de chaves assimétricas — a migração não é opcional.

Harvest-Now-Decrypt-Later é uma ameaça ativa

A razão pela qual a urgência importa agora, mesmo que computadores quânticos criptograficamente relevantes ainda não existam, é o ataque "colha agora, decifre depois" (HNDL). Adversários em nível de estado estão capturando tráfego criptografado hoje com a intenção de decifrá-lo quando a capacidade quântica estiver disponível. Estimativas do NIST, NSA e CISA colocam computadores quânticos criptograficamente relevantes (CRQCs) a 10-15 anos de distância — exatamente a janela em que dados capturados em 2026 poderiam ser decifrados quando ainda tiverem valor de inteligência.

Se sua aplicação lida com dados que devem permanecer confidenciais por uma década — registros financeiros, registros de saúde, comunicações, propriedade intelectual, contratos governamentais — o adversário não precisa de um computador quântico hoje. Ele precisa de um enquanto você ainda se importa que esses dados sejam secretos. A captura está acontecendo agora.

Triagem: o que migrar e quando

Nem tudo precisa ser movido simultaneamente. A ordem correta de triagem é: troca de chaves primeiro, assinaturas em segundo, criptografia simétrica por último (ou nunca).

1. Troca de chaves — maior prioridade

A troca de chaves RSA e ECDH é a primeira coisa que os computadores quânticos quebram. Substitua-as por ML-KEM (Kyber). A rampa de entrada segura padrão é o modo híbrido: executar simultaneamente o clássico e o PQC. Se ML-KEM tiver uma fraqueza não descoberta, o algoritmo clássico ainda o protege. Se um CRQC aparecer, a camada PQC o cobre.

X25519MLKEM768 é o híbrido específico usado pelo Chrome, Cloudflare e AWS em TLS de produção hoje. Sua pilha web pode já suportá-lo: OpenSSL 3.5 (lançado em abril de 2025) inclui suporte completo para ML-KEM e ML-DSA. Habilitá-lo é tipicamente uma alteração de configuração, não de código.

2. Assinaturas digitais — prioridade média

ML-DSA (Dilithium) substitui RSA-PSS e ECDSA para assinatura. A urgência aqui é menor porque as assinaturas não têm o problema HNDL — uma assinatura só precisa ser válida no momento da verificação, não daqui a uma década. Coloque certificados de assinatura de código, assinaturas de documentos de longa duração e hierarquias de CA internas em seu roteiro 2027–2028, não em seu sprint de 2026.

3. Criptografia simétrica — prioridade baixa

AES-256 e SHA-256 não são quebrados por computadores quânticos. O algoritmo de Grover reduz pela metade seu comprimento efetivo de chave, razão pela qual o AES-256 tem sido a recomendação padrão por anos. Se você já está usando chaves simétricas de 256 bits, a criptografia simétrica não requer migração. Se ainda estiver usando AES-128 por desempenho, atualize para AES-256 — essa é a extensão do trabalho aqui.

Prontidão das bibliotecas em meados de 2026

O ecossistema convergiu para os padrões FIPS finalizados em todas as principais linguagens:

Go

O pacote padrão crypto/tls suporta X25519MLKEM768 a partir do Go 1.24. Para operações diretas de ML-KEM fora do TLS, golang.org/x/crypto inclui suporte estável para ML-KEM 768 e 1024. A API reflete os padrões de chave assimétrica existentes: GenerateKey, Encapsulate, Decapsulate com slices de bytes tipados.

Python

pyca/cryptography 44.0.0 (novembro de 2024) adicionou ML-KEM por meio de seu backend OpenSSL 3.5. A interface segue o mesmo padrão generate_private_key / exchange das operações EC existentes. Para ambientes onde você não pode controlar a versão do OpenSSL, pqcrypto fornece uma ligação direta às implementações de referência em C.

Rust

O crate ml-kem do projeto RustCrypto é uma implementação puramente Rust, compatível com no_std e totalmente compatível com FIPS 203. Ele suporta as variantes ML-KEM-512, 768 e 1024 e é a escolha certa para destinos embarcados ou WASM onde você não pode vincular o OpenSSL. Para fazer a ponte com implantações Kyber pré-padrão, pqcrypto-kyber permanece disponível.

Java / JVM

BouncyCastle 1.77+ suporta ML-KEM e ML-DSA com uma API estável. O OpenJDK 24 introduziu ML-KEM como uma API de pré-visualização sob JEP 496, com GA previsto para JDK 25. Para implantações JVM de produção hoje, o BouncyCastle é o caminho confiável.

Habilitando PQC híbrido em seu Service Mesh

Para mTLS interno serviço a serviço, o PQC híbrido é alcançável sem alterações no código da aplicação. O Envoy Proxy 1.32+ suporta o híbrido X25519+ML-KEM quando compilado contra OpenSSL 3.5. A mudança é uma atualização de configuração do service mesh na sua lista de conjuntos de cifras TLSParameters. Tanto Istio quanto Linkerd têm caminhos de migração documentados para essa configuração.

Para TLS de borda, Cloudflare e AWS CloudFront já negociam X25519MLKEM768 quando o cliente suporta. Se você termina o TLS em uma CDN ou balanceador de carga que não controla, verifique o changelog do seu provedor — você pode já ter cobertura parcial de PQC sem saber.

Um cronograma concreto de três anos

2026: Audite toda a troca de chaves nos serviços voltados para o exterior. Identifique as versões do OpenSSL em toda a frota. Habilite X25519MLKEM768 nos endpoints HTTPS (alteração de configuração). Documente todo uso de RSA e ECDH em contextos não TLS: chaves SSH, JWTs, PKI interno, qualquer derivação de chave personalizada.

2027: Migre a troca de chaves não TLS para ML-KEM. Comece o redesign da hierarquia de CA interna. Mova a assinatura de código para ML-DSA para novos lançamentos de artefatos. Avalie a migração de chaves SSH (OpenSSH 9.x suporta KEX híbrido baseado em ML-KEM).

2028–2030: Complete a migração de assinaturas. Aposente o RSA de toda infraestrutura nova. Alcance alinhamento com NIST SP 800-131C e requisitos regulatórios aplicáveis (diretrizes HIPAA, disposições PQC do PCI-DSS 5.0, padrões técnicos da Lei de Ciberresiliência da UE).

Conclusões práticas

• Habilite X25519MLKEM768 em TLS 1.3 em endpoints públicos hoje — é uma mudança de configuração com sobrecarga de desempenho insignificante em hardware moderno e protege contra HNDL imediatamente.
• Atualize para OpenSSL 3.5+ ou BouncyCastle 1.77+ antes de escrever qualquer novo código criptográfico; estes incluem as implementações finalizadas FIPS 203, 204 e 205.
• Audite sua superfície RSA e ECDH em TLS, SSH, assinatura JWT, PKI interno e qualquer troca de chave personalizada — troca de chaves é a maior prioridade, assinaturas são média, simétrica é a última.
• Use o modo híbrido (clássico + PQC simultaneamente) como seu caminho de migração, não uma transição brusca para PQC puro; isso corresponde ao que Google, Cloudflare, AWS e Apple implantaram.
• Se você lida com dados com requisito de confidencialidade de 10+ anos, trate HNDL como uma ameaça ativa atual e coloque a migração de troca de chaves PQC em seu roteiro de engenharia de 2026, não 2028.