Criptografia pós-quântica na prática: como verificar e ativar ML-KEM no TLS e no SSH

Não existe hoje um computador quântico capaz de quebrar RSA-2048 ou uma curva elíptica de 256 bits. Mesmo assim, a migração para criptografia pós-quântica (PQC) já roda em produção no navegador que você está usando. O motivo tem nome: harvest now, decrypt later. Quem grava o tráfego cifrado hoje pode guardar e decifrar daqui a dez ou quinze anos, se a máquina aparecer.

Isso muda a prioridade. Assinatura digital só precisa resistir enquanto o certificado vale. A troca de chaves precisa proteger o segredo pelo tempo que ele tiver valor. Prontuário médico, contrato, credencial de longa duração: tudo isso passa por TLS e SSH e pode ser capturado agora.

Este texto é o mapa que eu uso para responder três perguntas: o que foi padronizado, o que já está ligado sem você fazer nada, e onde está o trabalho de verdade.

O que o NIST padronizou

Em agosto de 2024 o NIST publicou os três primeiros padrões finais de PQC:

• FIPS 203 — ML-KEM (derivado do CRYSTALS-Kyber): mecanismo de encapsulamento de chave. É o substituto do ECDH e do RSA na troca de chaves.
• FIPS 204 — ML-DSA (derivado do CRYSTALS-Dilithium): assinatura digital de uso geral.
• FIPS 205 — SLH-DSA (derivado do SPHINCS+): assinatura baseada só em funções hash. Lenta e grande, mas apoiada na hipótese de segurança mais conservadora que existe.

Em 2025 o instituto escolheu o HQC como KEM reserva. Ele se baseia em códigos corretores de erro, não em reticulados. A ideia é ter uma alternativa pronta caso apareça um ataque estrutural contra a matemática do ML-KEM.

O rascunho do NIST IR 8547 propõe o cronograma de saída: algoritmos vulneráveis a quântico com 112 bits de segurança (RSA-2048, P-256) ficam deprecated após 2030 e proibidos após 2035 em sistemas federais americanos. Na prática, esse calendário acaba virando referência para auditoria e compliance em outros lugares também.

O custo em bytes

A diferença que mais aparece em produção não é CPU, é tamanho. ML-KEM é rápido, muitas vezes mais rápido que ECDH. O problema é o que trafega na rede:

Algoritmo	Uso	Chave pública	Ciphertext / assinatura
X25519	Troca de chaves	32 bytes	32 bytes
ML-KEM-768	Troca de chaves	1.184 bytes	1.088 bytes
Ed25519	Assinatura	32 bytes	64 bytes
ECDSA P-256	Assinatura	64 bytes	~72 bytes
ML-DSA-65	Assinatura	1.952 bytes	3.309 bytes
SLH-DSA-128s	Assinatura	32 bytes	7.856 bytes

A troca de chaves cresce cerca de 1 KB em cada direção. Dá para absorver. Uma cadeia de certificados inteira em ML-DSA, com duas ou três assinaturas e chaves públicas, soma vários KB a cada handshake. Por isso a indústria atacou a troca de chaves primeiro e deixou a PKI para depois.

Por que híbrido, e não ML-KEM puro

Ninguém sério trocou ECDH por ML-KEM sozinho. O padrão de fato é o grupo híbrido X25519MLKEM768: cliente e servidor fazem as duas trocas, e o segredo final deriva das duas. Para quebrar o canal, o atacante precisa quebrar X25519 e ML-KEM.

O raciocínio é honesto: X25519 tem décadas de análise e perde para um quântico no futuro. ML-KEM resiste ao quântico, mas tem poucos anos de escrutínio público e implementações novas. O híbrido protege contra os dois cenários. A especificação para TLS 1.3 é o draft-ietf-tls-ecdhe-mlkem no IETF.

O que já está ligado sem você fazer nada

• Navegadores. O Chrome trocou o Kyber experimental pelo ML-KEM final no fim de 2024. Firefox, Edge e Safari seguiram caminhos parecidos. No Chrome, o painel Security das DevTools mostra o grupo de troca de chaves da conexão.
• CDNs. Quem publica atrás de uma CDN grande geralmente já negocia X25519MLKEM768 com navegadores modernos sem configurar nada. O Cloudflare Radar publica a fatia do tráfego que usa PQC.
• Go. A partir do Go 1.24, crypto/tls oferece X25519MLKEM768 por padrão. Servidor e cliente Go atualizados já negociam híbrido.
• OpenSSH. A versão 9.9 adicionou mlkem768x25519-sha256, e a 10.0 o tornou o padrão. Antes disso, desde a 9.0, o padrão já era outro híbrido, sntrup761x25519-sha512.
• OpenSSL 3.5 (LTS) traz ML-KEM, ML-DSA e SLH-DSA nativamente. Distribuições que empacotam 3.5 ganham PQC em Nginx, HAProxy, Postfix e tudo que linka OpenSSL.

O ponto fraco costuma estar no meio: proxy reverso antigo, load balancer, VPN, appliance de inspeção TLS, cliente Java ou .NET preso a uma versão velha.

Como verificar no seu ambiente

Qual OpenSSL você tem

openssl version
openssl list -kem-algorithms | grep -i ml-kem

Se o segundo comando não retornar nada, sua build não tem ML-KEM. Nginx e HAProxy vão herdar essa limitação.

O servidor aceita o grupo híbrido?

Com um OpenSSL 3.5 no cliente, force o grupo e veja se o handshake fecha:

openssl s_client -connect exemplo.com.br:443 \
  -groups X25519MLKEM768 -brief </dev/null 2>&1 | grep -iE "group|protocol"

Se o servidor não suporta o grupo, o handshake falha, porque você não ofereceu alternativa. Para ver o que ele escolhe entre várias opções, passe uma lista: -groups X25519MLKEM768:X25519.

Nginx

Com Nginx linkado a OpenSSL 3.5, a diretiva ssl_ecdh_curve define a lista de grupos, na ordem de preferência:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

O fallback para X25519 e prime256v1 mantém clientes antigos funcionando. Grupo híbrido só existe no TLS 1.3; clientes TLS 1.2 caem na curva clássica.

OpenSSH

Veja o que seu cliente suporta e o que foi negociado:

ssh -Q kex | grep -E "mlkem|sntrup"
ssh -v usuario@servidor exit 2>&1 | grep "kex: algorithm"

Para exigir troca de chaves pós-quântica no servidor, em /etc/ssh/sshd_config:

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256

Deixei curve25519-sha256 no fim de propósito. Remover os algoritmos clássicos tranca para fora quem ainda usa cliente antigo, inclusive automações e ferramentas de deploy que você esqueceu que existiam. Remova só depois de olhar os logs e saber quem negocia o quê.

O que quebra

ClientHello grande. Com ML-KEM, o primeiro pacote do handshake passa de ~1.200 bytes e pode ser dividido em dois segmentos TCP. Servidores e middleboxes que assumiam o ClientHello num único pacote falharam nos testes dos navegadores. O site tldr.fail documenta o problema e lista implementações afetadas. Se um cliente moderno falha só para um destino, e um cliente antigo funciona, suspeite disso antes de qualquer outra coisa.

Inspeção TLS corporativa. Proxies que terminam TLS precisam suportar os grupos novos dos dois lados. Se o proxy não suporta, o navegador negocia o grupo clássico com o proxy, e a proteção pós-quântica some sem aviso naquele trecho.

HSMs e hardware. Módulos de hardware, tokens e firmwares embarcados trocam de algoritmo em ciclos de anos, não de meses. É onde RSA vai sobreviver por mais tempo.

Onde está o trabalho de verdade: inventário

A parte fácil, ligar híbrido no TLS e no SSH, a maioria dos times resolve com atualização de pacote. A parte difícil é saber onde RSA e ECC estão embutidos:

• certificados internos, CA privada e mTLS entre serviços;
• JWT assinados com RS256 ou ES256, com chaves que ninguém rotaciona;
• VPN site-to-site e IPsec;
• assinatura de artefatos, pacotes e imagens de container;
• criptografia de backup com chave assimétrica;
• protocolos proprietários de fornecedores e dispositivos IoT.

A pergunta útil para cada item não é "já é pós-quântico?". É "consigo trocar o algoritmo sem reescrever o sistema?". Isso tem nome, crypto-agility, e é o que separa uma migração de configuração de uma migração de projeto.

Checklist

• OpenSSL 3.5+ (ou biblioteca equivalente) nos proxies e servidores de borda.
• X25519MLKEM768 como primeiro grupo no TLS 1.3, com fallback clássico.
• OpenSSH 10.x nos servidores; conferir no log qual kex os clientes negociam.
• Testar o handshake através de cada middlebox: WAF, load balancer, proxy corporativo.
• Inventário de onde RSA/ECC aparecem fora do TLS, com dono e prazo para cada item.
• Priorizar dados com vida longa: o que precisa continuar secreto depois de 2035 é o que deveria migrar primeiro.

Em resumo

A criptografia pós-quântica deixou de ser pesquisa: é configuração padrão nos navegadores, em Go, no OpenSSH e no OpenSSL. A troca de chaves híbrida resolve o risco mais urgente, que é tráfego gravado hoje e decifrado depois. O que falta é menos glamouroso: achar cada lugar onde uma chave RSA está escondida e garantir que dá para trocá-la antes de 2030.

Fontes

• NIST FIPS 203 (ML-KEM)
• NIST FIPS 204 (ML-DSA)
• NIST FIPS 205 (SLH-DSA)
• NIST IR 8547 — Transition to Post-Quantum Cryptography Standards
• IETF draft-ietf-tls-ecdhe-mlkem
• OpenSSH Release Notes
• OpenSSL 3.5.0
• Go 1.24 Release Notes — crypto/tls
• tldr.fail — ClientHello grande e implementações quebradas
• Cloudflare Radar — Adoption and Usage