PQC StatusCRYSTALS-Kyber e ML-KEM não são dois algoritmos. O ML-KEM é a forma padronizada do CRYSTALS-Kyber, publicada pelo NIST como FIPS 203 em 13 de agosto de 2024. A mudança não é cosmética: o FIPS 203 é uma especificação com seus próprios nomes de conjuntos de parâmetros, seus próprios formatos de chave e suas próprias regras de validação, e uma implementação da submissão original da competição não interopera com uma implementação de ML-KEM. No TLS, é por isso que o grupo pré-padrão X25519Kyber768Draft00 (codepoint 0x6399) está obsoleto e precisa ser substituído pelos grupos ML-KEM.
Um design, dois nomes, uma especificação aprovada
Um KEM (key encapsulation mechanism, mecanismo de encapsulamento de chave) é o componente de um handshake que permite a duas partes acordar um segredo compartilhado. CRYSTALS-Kyber era o nome do KEM baseado em reticulados submetido ao processo de padronização pós-quântica do NIST. Quando o NIST publicou o padrão final, o algoritmo foi renomeado ML-KEM, abreviação de Module-Lattice-Based Key-Encapsulation Mechanism, e especificado no FIPS 203. Ele foi publicado no mesmo dia que o FIPS 204 (ML-DSA, assinaturas) e o FIPS 205 (SLH-DSA, assinaturas baseadas em hash sem estado).
Em uma conversa, Kyber e ML-KEM se referem à mesma família de designs. Em código, em uma lista de grupos ou em um documento de conformidade, eles não são intercambiáveis. Somente o ML-KEM conforme especificado no FIPS 203 é um padrão aprovado. Tudo o que ainda está rotulado como Kyber, Kyber768 ou Draft00 é anterior a ele. Nossa página de referência sobre ML-KEM acompanha o padrão e seu status, e a página sobre o rascunho Kyber acompanha os grupos pré-padrão que agora devem ser removidos das configurações.
O que a passagem do rascunho ao padrão final mudou
O FIPS 203 foi divulgado como rascunho público inicial para comentários antes de o NIST publicar o texto final. Três categorias de mudança importam para um engenheiro ou um arquiteto.
Nomes e conjuntos de parâmetros
Kyber512, Kyber768 e Kyber1024 tornaram-se ML-KEM-512, ML-KEM-768 e ML-KEM-1024. O FIPS 203 especifica exatamente esses três conjuntos de parâmetros. Uma opção de build, uma constante ou um vetor de teste que ainda traz um nome Kyber é um sinal de que o código não foi atualizado, e não simplesmente de que alguém manteve um rótulo antigo.
Detalhes de especificação que quebram a interoperabilidade
O padrão final difere da submissão original da competição em detalhes de especificação que incluem a geração de chaves, a codificação de chaves e a derivação do segredo compartilhado. Esses detalhes são normativos no FIPS 203 e devem ser lidos diretamente nele, e não em resumos de segunda mão. A consequência prática é simples e absoluta: um par que executa Kyber pré-padrão e um par que executa ML-KEM não derivarão o mesmo segredo compartilhado. Não há negociação entre eles, nem caminho de downgrade, nem compatibilidade parcial. O handshake falha, ou o grupo simplesmente nunca é selecionado.
Regras que uma implementação precisa seguir
O FIPS 203 também especifica verificações que uma implementação realiza sobre o material de chave recebido antes de usá-lo, e define o comportamento do desencapsulamento quando a entrada não é válida (rejeição implícita, que retorna um segredo compartilhado pseudoaleatório em vez de um erro). Os autores de bibliotecas carregam a maior parte desse peso. Para quem consome uma biblioteca, a lição é preferir uma implementação mantida que declare conformidade com o FIPS 203 a uma cópia do código de referência do período da competição, e verificar as notas de versão em vez do nome do algoritmo.
Os três conjuntos de parâmetros: 512, 768 e 1024
O FIPS 203 define os três conjuntos de parâmetros em relação às categorias de segurança do NIST. O número não é um tamanho de chave em bits: é um rótulo do conjunto de parâmetros.
| Conjunto de parâmetros | Categoria de segurança NIST | Onde aparece na prática |
|---|---|---|
| ML-KEM-512 | Categoria 1 | Registrado como grupo TLS puro (codepoint 512). Raramente implantado isoladamente para tráfego web público. |
| ML-KEM-768 | Categoria 3 | A escolha de facto do ecossistema: X25519MLKEM768 nos navegadores, mlkem768x25519-sha256 no OpenSSH. |
| ML-KEM-1024 | Categoria 5 | Exigido pelo NSA CNSA 2.0 para os National Security Systems dos EUA. Combinado com P-384 em SecP384r1MLKEM1024. |
Para TLS e SSH de uso geral, o ML-KEM-768 dentro de uma construção híbrida é onde o ecossistema convergiu. Se você opera sistemas no escopo do NSA CNSA 2.0, a suíte especifica ML-KEM-1024 junto com ML-DSA-87, LMS ou XMSS, AES-256 e SHA-384 ou SHA-512, com uso exclusivo esperado até o fim de 2030 para assinatura de software e firmware e equipamentos de rede tradicionais, e até o fim de 2033 para navegadores e servidores web, serviços em nuvem e sistemas operacionais. Outras autoridades apresentam suas posições como recomendações: a BSI TR-02102-1 recomenda o acordo de chaves pós-quântico híbrido, e a ANSSI torna a hibridização obrigatória dentro do seu escopo regulado, ao mesmo tempo em que afirma que suas recomendações pós-quânticas ainda não são obrigações regulatórias fora dele. Este artigo é informativo e não constitui aconselhamento jurídico.
Grupos TLS: o que é atual, o que é obsoleto
O grupo nomeado é a parte visível de tudo isso. Somente os codepoints abaixo existem no registro da IANA para ML-KEM, e apenas um deles é a entrada pré-padrão obsoleta.
| Grupo | Codepoint | Status |
|---|---|---|
| X25519Kyber768Draft00 | 0x6399 | Kyber pré-padrão. Obsoleto. Remova-o. |
| X25519MLKEM768 | 0x11EC (4588) | Híbrido. Oferecido por padrão pelas versões atuais do Chrome, Edge e Firefox. |
| SecP256r1MLKEM768 | 0x11EB (4587) | Híbrido, para stacks padronizadas em curvas NIST. |
| SecP384r1MLKEM1024 | 0x11ED (4589) | Híbrido, perfil de categoria 5. |
| MLKEM512 / MLKEM768 / MLKEM1024 | 512 / 513 / 514 | ML-KEM puro, sem componente clássico. Não é um padrão para servidores web públicos hoje. |
Os grupos híbridos combinam um acordo de chaves clássico com o ML-KEM, de modo que a sessão permanece pelo menos tão forte quanto a parte clássica caso uma fraqueza seja encontrada na construção em reticulados, e ganha proteção pós-quântica contra tráfego gravado. Essa combinação é descrita para o TLS 1.3 no RFC 10024 (agosto de 2026). O tráfego gravado é protegido apenas pela troca de chaves, e é por isso que o acordo de chaves migra primeiro e os certificados podem vir depois. A página sobre X25519MLKEM768 detalha o grupo que a maioria dos servidores deve habilitar primeiro.
O que verificar em bibliotecas, servidores e SSH
Execute primeiro verificações somente leitura, em um host de homologação, antes de tocar em uma configuração de produção.
OpenSSL
O OpenSSL 3.5 ou posterior é necessário para os grupos TLS ML-KEM. Um branch mais antigo ainda pode anunciar um grupo de rascunho Kyber por meio de um provider ou de um patch da distribuição: é esse o caso a encontrar e remover.
openssl version
openssl list -tls-groups | grep -i mlkem
openssl s_client -connect example.com:443 -groups X25519MLKEM768Na saída do s_client, leia o grupo negociado. Se a conexão falhar com um erro de handshake enquanto um grupo clássico funciona, o servidor ainda não oferece suporte ao ML-KEM.
Configuração do servidor
Mantenha sempre um fallback clássico após o grupo híbrido para que clientes mais antigos continuem se conectando. No nginx compilado com OpenSSL 3.5 ou posterior:
ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;A sintaxe e os valores suportados variam entre servidores e entre builds de distribuições, portanto verifique na sua própria versão. Nosso guia para habilitar o ML-KEM no nginx, Apache, HAProxy e Caddy apresenta a diretiva de cada um.
SSH
O OpenSSH 9.9 (19 de setembro de 2024) adicionou mlkem768x25519-sha256, disponível por padrão. O OpenSSH 10.0 (9 de abril de 2025) o tornou o acordo de chaves padrão, e o OpenSSH 10.1 (6 de outubro de 2025) emite um aviso quando uma conexão negocia um acordo de chaves que não é pós-quântico, por meio da opção WarnWeakCrypto, habilitada por padrão. Versões anteriores, a partir do OpenSSH 9.0, usam por padrão o híbrido sntrup761x25519-sha512@openssh.com, que é pós-quântico, mas não é ML-KEM.
ssh -V
ssh -Q kex | grep mlkemCódigo da aplicação e dependências
- Pesquise nos seus repositórios e na sua gestão de configuração as strings
Kyber,kyber768,Draft00e0x6399. Cada ocorrência é código morto ou uma configuração incorreta ativa. - Verifique as listas de grupos fixadas em balanceadores de carga, CDNs, gateways de API, proxies reversos e terminadores TLS. Uma lista fixada é o motivo mais comum para uma biblioteca moderna ainda negociar um grupo clássico.
- Verifique nas notas de versão da sua biblioteca criptográfica, e não no nome do algoritmo, a declaração de que a implementação segue o FIPS 203. Quando a validação FIPS for relevante para você, verifique o status de validação do módulo e da versão específicos que você distribui.
- Registre no seu inventário o conjunto de parâmetros, e não apenas o algoritmo: ML-KEM-768 e ML-KEM-1024 são respostas diferentes para um auditor que pergunta qual deles você implantou.
Verifique o que seus servidores realmente negociam
A forma mais rápida de saber se um domínio está no padrão ou ainda em um grupo de rascunho é observar o que ele oferece na rede. Você pode escanear seu domínio com o PQC Status gratuitamente: o scanner informa os grupos ML-KEM híbridos que um servidor aceita, as versões de TLS e as cipher suites, além da cadeia de certificados. Um scan descreve apenas a configuração TLS visível externamente. Não é uma certificação nem um atestado de conformidade. O próximo passo concreto para este tema: confirme que cada endpoint público oferece X25519MLKEM768 com um fallback clássico e, em seguida, remova qualquer referência restante ao grupo Kyber pré-padrão da sua configuração e do seu inventário.