Resumo

  • A RFC 10024 define X25519MLKEM768, SecP256r1MLKEM768 e SecP384r1MLKEM1024 para combinar ML-KEM com um componente tradicional de curva elíptica no acordo de chaves do TLS 1.3.
  • A derivação do segredo de sessão e a autenticação do servidor são operações separadas. Migrar o acordo de chaves não troca automaticamente o certificado nem a assinatura CertificateVerify.
  • Bas Westerbaan escreveu a RFC com Krzysztof Kwiatkowski, Panos Kampanakis e Douglas Stebila. O padrão entrega um marco verificável de migração, não uma garantia sobre todos os saltos e dados de um serviço.

O termo “conexão pós-quântica” comprime decisões demais. Que algoritmo protege o segredo de sessão? Qual assina o transcript? Onde o TLS termina? O que acontece depois que os bytes são decifrados? As respostas podem seguir cronogramas diferentes sem que o protocolo esteja em contradição.

Publicada como Proposed Standard do IETF em agosto de 2026, a RFC 10024 resolve uma parte bem definida. Ela cria três grupos suportados pelo TLS 1.3. Um combina X25519 com ML-KEM-768; os outros usam secp256r1 com ML-KEM-768 e secp384r1 com ML-KEM-1024. As duas parcelas entram na construção do segredo compartilhado conforme o formato e a ordem especificados.

O adversário central é paciente. Ele grava hoje o tráfego cifrado e espera que um computador quântico criptograficamente relevante quebre amanhã o estabelecimento clássico de chaves. O híbrido PQ/T evita depender apenas da família tradicional e, ao mesmo tempo, não apoia toda a segurança somente no componente pós-quântico mais recente.

É proteção real contra uma exposição real. Ela não se espalha para outras operações por proximidade.

Uma sessão, duas provas criptográficas

No TLS 1.3, o resultado da troca de chaves alimenta a programação que deriva as chaves de tráfego. Em um handshake com certificado, a cadeia de confiança e a assinatura CertificateVerify autenticam o servidor. Os elementos participam do mesmo transcript, mas produzem evidências distintas.

O acordo híbrido demonstra como os extremos formaram o segredo da conexão. A assinatura demonstra que o extremo possui a chave privada associada a uma identidade certificada e confirmou o transcript com um esquema aceito. A primeira conclusão não contém a segunda.

A RFC 9794 separa as famílias no vocabulário: estabelecimento híbrido de chaves PQ/T, KEM híbrido, criptografia híbrida de chave pública e assinatura digital híbrida. Cada uma pode amadurecer e ser implantada em ritmo próprio. A RFC 9935 define identificadores X.509 para chaves ML-KEM, mas um identificador não cria uma cadeia de emissão confiável e ML-KEM não se transforma em assinatura digital.

Também existem dois atacantes. O passivo quer decifrar no futuro uma sessão arquivada; o acordo híbrido reduz essa oportunidade. O ativo do futuro quer forjar uma assinatura clássica e se passar pelo servidor; esse risco exige migração de assinaturas, certificados, emissão e validação. Ambos são riscos quânticos. Os controles não são substitutos.

A evidência útil de uma migração incompleta

A biografia de Bas Westerbaan na Cloudflare Research o apresenta como Research Engineer que trabalha para levar a criptografia pós-quântica da engenharia e padronização a experimentos em grande escala e implantação. O registro oficial do IETF inclui a RFC 10024 e outros trabalhos do tema.

Essa continuidade profissional não apaga a autoria coletiva. Krzysztof Kwiatkowski, Panos Kampanakis e Douglas Stebila assinam a RFC com Westerbaan. O texto depende da construção geral da RFC 9954, da terminologia da RFC 9794, do TLS 1.3 e do padrão ML-KEM do NIST. A contribuição deve ser atribuída à equipe e ao processo de padrões.

Em setembro de 2025, a Cloudflare publicou um retrato particularmente claro da implantação por fases. Mais de um terço do tráfego gerado por pessoas para sua rede usava TLS 1.3 com acordo híbrido pós-quântico de chaves. No mesmo artigo, a empresa disse que assinaturas e certificados pós-quânticos ainda estavam em padronização para TLS e PKI da Internet e que o WARP ainda não havia sido atualizado para eles.

O número não é uma taxa mundial e não descreve todas as configurações posteriores. Tampouco audita os saltos internos da empresa. Ele comprova algo mais preciso: uma propriedade pode chegar a escala de produção enquanto a autenticação vizinha continua clássica. Tratar essa sinceridade como falha seria um erro; tratar a primeira propriedade como conclusão total seria outro.

O alcance de uma negociação bem-sucedida

Quando o cliente anuncia grupos em supported_groups, há evidência de capacidade ou preferência. Ainda não há seleção. Quando o servidor escolhe um grupo da RFC 10024, há evidência do acordo naquele ponto visível. Ainda não há auditoria de implementação, aleatoriedade, canal lateral ou retorno oculto.

O handshake concluído mostra que os extremos produziram chaves utilizáveis. Para avaliar autenticação, é preciso capturar a cadeia de certificados e o algoritmo da assinatura. Para avaliar cobertura, é preciso localizar terminação TLS, proxies, origem, malha de serviços, túneis, retomada de sessão e 0-RTT.

Depois da terminação, os dados passam a outros controles. Logs, bancos, filas e backups podem usar chaves próprias ou ficar em claro. Revogação de certificados, rotação de tickets de sessão, segredos de aplicação e recuperação de dados armazenados não aparecem no nome do grupo negociado.

A própria RFC 10024 impede uma generalização tentadora. Ela alerta que não se deve presumir segura uma hibridização semelhante em outros protocolos. O combinador, a ordem, os comprimentos, o transcript e o modelo de ameaça fazem parte da análise. Colocar dois algoritmos lado a lado não reproduz automaticamente essas propriedades.

A RFC 9851 congela novos recursos no TLS 1.2 e direciona a inovação ao TLS 1.3. Isso reduz improvisos no protocolo antigo, mas não faz certificados, bibliotecas, hardware, proxies e armazenamento migrarem juntos.

Transformar o selo em recibo operacional

A primazia do código em execução de Heng Lu oferece um teste simples: uma declaração não é o resultado. O recibo pós-quântico precisa permitir que outra equipe reproduza a observação.

Ele deve ligar cliente, extremo, data, versão TLS, grupos anunciados e escolhidos, versão da implementação, cadeia de certificados, assinatura CertificateVerify, terminação, retomada, proteção dos saltos seguintes e ponto em que o dado aparece em claro. Método, acesso e limitações do teste também fazem parte do registro.

Esses campos revelam os donos. O IETF especifica; navegadores e bibliotecas implementam; operadores configuram; autoridades certificadoras emitem; redes controlam proxies; aplicações armazenam; resposta a incidentes revoga e recupera. Uma única luz verde não conclui a obrigação de todos.

A melhor leitura da RFC 10024 é, portanto, concreta: uma etapa importante do acordo de chaves agora pode ser nomeada, negociada e verificada. O certificado ainda precisa apresentar o próprio recibo.

Fontes