Boa parte dos handshakes TLS da web já combina uma curva elíptica dos anos 1990 com um algoritmo baseado em reticulados (lattices) que só foi padronizado em 2024. Essa combinação se chama X25519MLKEM768 e, sem alarde, virou um mecanismo padrão de troca de chaves nos principais navegadores. Não porque alguém tenha construído um computador quântico capaz de quebrar curvas elípticas, mas porque alguém pode vir a construir, e o tráfego gravado hoje ainda vai ter valor quando isso acontecer. É a parte mais concreta, e já em produção, da transição pós-quântica, e vale a pena entendê-la em detalhe.

Por que híbrido, e não substituição

O caminho óbvio seria abandonar o e usar só o . A indústria decidiu não fazer isso, por um motivo: o ML-KEM é novo. A dificuldade dos problemas de reticulados é estudada há anos, mas um esquema padronizado há pouco tempo é uma superfície de ataque bem mais jovem do que o X25519, que tem décadas de análise nas costas. E a área ainda se lembra bem do que uma premissa jovem pode fazer: o (Supersingular Isogeny Key Encapsulation), um esquema baseado em isogenias, foi quebrado em 2022 por um ataque clássico, depois de anos como candidato sério. Apostar a troca de chaves inteira só no ML-KEM significaria que um resultado inesperado de criptoanálise contra ele quebraria tudo.

O híbrido elimina esse ponto único de falha. Você faz uma troca clássica e uma pós-quântica no mesmo handshake e combina os resultados, e a chave de sessão fica segura enquanto pelo menos uma das duas resistir. Se um computador quântico um dia quebrar o X25519, o ML-KEM ainda protege você; se aparecer uma quebra clássica inesperada contra o ML-KEM, o X25519 ainda protege você. É defesa em profundidade aplicada ao handshake e é, declaradamente, uma postura de transição: a resposta certa para os próximos anos, não um estado final permanente.

O que é o X25519MLKEM768

O X25519MLKEM768 é um named group (grupo nomeado) do TLS 1.3, com o codepoint 0x11EC, que junta dois métodos de estabelecimento de chaves:

  • X25519, a troca clássica de curva elíptica sobre a Curve25519, a mesma que já está em todo lugar no TLS moderno.
  • ML-KEM-768, o mecanismo de encapsulamento de chaves baseado em reticulados do 203, no conjunto de parâmetros intermediário.

Ele é definido na 10024 (agosto de 2026), publicada a partir do draft da draft-ietf-tls-ecdhe-mlkem (adotado pelo grupo de trabalho TLS em março de 2025), que especifica três híbridos desse tipo: o X25519MLKEM768 e, para quem usa as curvas do , o SecP256r1MLKEM768 e o SecP384r1MLKEM1024. O X25519MLKEM768 é o que praticamente todo navegador traz, e a Cloudflare informou que ele responde pela grande maioria das conexões pós-quânticas que ela recebe. A construção que ele usa, um híbrido concatenado que junta os dois segredos compartilhados e passa o resultado pela função de derivação de chaves, é o padrão descrito na RFC 9954.

Na rede, o ClientHello anuncia o X25519MLKEM768 na extensão supported_groups e manda uma entrada key_share que concatena os dois valores públicos: uma chave de encapsulamento ML-KEM-768 (1184 bytes) e uma chave pública efêmera X25519 (32 bytes), num total de 1216 bytes. Se o servidor suporta o grupo, ele valida o material de chave do ML-KEM, gera a sua chave efêmera X25519, faz o encapsulamento ML-KEM com a chave do cliente e devolve cerca de 1120 bytes (o texto cifrado do ML-KEM, de 1088 bytes, mais o valor X25519, de 32 bytes). Agora os dois lados têm dois segredos compartilhados. Eles são concatenados numa ordem fixa, primeiro o segredo do ML-KEM e depois o do X25519, e entram no key schedule (a sequência de derivação de chaves) normal do TLS 1.3. Desde que a etapa de derivação de chaves seja segura, o segredo combinado continua seguro se qualquer uma das entradas for segura, e essa é exatamente a propriedade que o híbrido existe para garantir.

O problema do tamanho

O problema de engenharia que define o TLS pós-quântico não é a matemática: é o tamanho. Um ClientHello clássico, com X25519, cabe com folga num único segmento TCP. O ML-KEM-768 aumenta o ClientHello em cerca de 1,2 kilobyte, e muitas vezes ele deixa de caber num segmento, ou num frame (quadro) padrão de 1500 bytes, e passa a ocupar dois pacotes.

Parece inofensivo, mas não é. Muito middleware de rede (firewalls, sistemas de detecção de intrusão, load balancers e outros middleboxes) foi escrito com a premissa, nunca dita, de que o ClientHello inteiro chega no primeiro pacote. Quando isso não acontece, parte desses equipamentos trata errado ou descarta o handshake dividido, e aparece um modo de falha novo e confuso: o TLS funciona bem no modo clássico, mas falha, ou faz downgrade em silêncio, no momento em que o grupo pós-quântico é oferecido. O problema é real o bastante para que o Chrome já tenha revertido a implantação do híbrido depois que ela atrapalhou handshakes em redes corporativas cujos middleboxes não davam conta. Se você opera um load balancer ou um equipamento de inspeção na frente de servidores TLS, é isso que você precisa testar antes de habilitar o grupo.

Em que pé está a implantação

A adoção do lado do cliente andou rápido. O Chrome passou a trazer o antecessor pré-padrão (X25519Kyber768Draft00), habilitado por padrão, na versão 124 (abril de 2024), e depois trocou pelo X25519MLKEM768 padronizado na versão 131 (novembro de 2024); o Edge veio junto, pelo Chromium que os dois compartilham. O Firefox habilitou o grupo por padrão para HTTPS na versão 132, e o suporte em QUIC/HTTP3 chegou na versão 135. A Apple acrescentou suporte no iOS 26 e no macOS 26, no fim de 2025. Do lado dos servidores e das bibliotecas, o OpenSSL 3.5 (abril de 2025) foi a primeira versão estável com ML-KEM nativo, o que dispensou o plug-in de provider do Open Quantum Safe; o Go habilitou o X25519MLKEM768 por padrão a partir do Go 1.24, e com isso o grupo foi ligado, sem alarde, em sistemas feitos em Go, inclusive nas versões recentes do . Na borda, Cloudflare, Google e outros suportam o grupo híbrido há anos e relatam uma parcela grande, e crescente, de conexões iniciadas por pessoas que já usam esse grupo.

Para o retrato ficar honesto, duas ressalvas. Primeiro, a cobertura diminui depois da borda entre o navegador e a (rede de distribuição de conteúdo): muitas instalações self-hosted de Apache, nginx e HAProxy ainda negociam o X25519 clássico, porque o operador não habilitou o grupo, porque o build do TLS é antigo demais ou porque um load balancer na frente descarta o handshake grande demais. Segundo, troca de chaves híbrida não é a mesma coisa que ser pós-quântico. Ela protege a confidencialidade contra o harvest now, decrypt later (colher agora, decifrar depois), que é a parte urgente, mas a autenticação é uma migração separada: as assinaturas dos certificados ainda são clássicas na maior parte da web, e levá-las para o ML-DSA (e para as formas de transição compostas com ) é a próxima frente. Implantar o X25519MLKEM768 num load balancer é um passo real e que vale a pena; é o mínimo, não a linha de chegada. Para os algoritmos que estão por baixo, veja os artigos sobre a ameaça quântica e sobre os padrões do NIST.

Para ver tudo isso acontecendo em uma conexão real, The Illustrated TLS 1.3 Connection anota cada byte de um handshake TLS 1.3 de verdade, registro por registro e campo por campo.

Fontes