---
title: "Criptografia pós-quântica na prática: como verificar e ativar ML-KEM no TLS e no SSH"
description: "O que os FIPS 203, 204 e 205 padronizaram, por que a troca de chaves híbrida X25519MLKEM768 virou padrão, e os comandos para conferir e ativar PQC em Nginx, Go e OpenSSH."
date: "2026-09-29"
tags: ["criptografia", "pos-quantica", "tls", "ssh", "seguranca", "nist", "openssl"]
url: "https://abjr.dev/noticias/criptografia-pos-quantica-ml-kem-tls"
---

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

```bash
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:

```bash
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:

```nginx
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:

```bash
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`:

```text
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)](https://csrc.nist.gov/pubs/fips/203/final)
- [NIST FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final)
- [NIST FIPS 205 (SLH-DSA)](https://csrc.nist.gov/pubs/fips/205/final)
- [NIST IR 8547 — Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd)
- [IETF draft-ietf-tls-ecdhe-mlkem](https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/)
- [OpenSSH Release Notes](https://www.openssh.com/releasenotes.html)
- [OpenSSL 3.5.0](https://github.com/openssl/openssl/releases/tag/openssl-3.5.0)
- [Go 1.24 Release Notes — crypto/tls](https://go.dev/doc/go1.24)
- [tldr.fail — ClientHello grande e implementações quebradas](https://tldr.fail/)
- [Cloudflare Radar — Adoption and Usage](https://radar.cloudflare.com/adoption-and-usage)