Resumo

  • RFC 10024 registra três grupos TLS 1.3 com ordem, tamanho, validação e concatenação exatos para segredos ECDHE e ML-KEM.
  • A robustez contra a quebra de um componente não equivale à independência operacional. O RFC alerta que um mesmo RNG inseguro pode permitir que a exposição por um algoritmo afete o outro.
  • A comprovação precisa separar o grupo negociado da fonte de entropia, do limite certificado, do terminador efetivo, da assinatura do certificado e das permissões de rollback.

A fronteira desenhada no diagrama não era a fronteira do módulo

Um banco contrata um appliance criptográfico descrito como híbrido. No desenho de arquitetura, P-256 aparece de um lado e ML-KEM-768 do outro. A equipe de compras lê “duas tecnologias” e registra “dois controles”. O relatório de conformidade menciona ainda um módulo FIPS para o primeiro segredo.

Ao abrir a composição do produto, surge outro mapa. O mesmo firmware agenda as duas operações. A mesma área de memória recebe os segredos. O mesmo serviço de aleatoriedade alimenta ECDHE e ML-KEM. A mesma conta remota troca a política de grupos. O mesmo pacote de emergência volta os dois componentes para uma versão anterior.

O grupo negociado pode estar perfeitamente correto. O erro está em tratar diversidade matemática como uma topologia operacional pronta. Se a raiz compartilhada falhar, as duas colunas do diagrama podem cair juntas.

RFC 10024, publicado no Standards Track do IETF em agosto de 2026, define três mecanismos híbridos Post-Quantum Traditional para o TLS 1.3. Cada um combina uma troca efêmera de curva elíptica com ML-KEM. A finalidade é preservar o segredo da sessão se pelo menos um dos mecanismos componentes continuar seguro.

Essa é uma propriedade da construção sob premissas definidas. Não é um atestado sobre todos os componentes de um appliance, de uma nuvem ou de uma equipe.

O NamedGroup é uma construção ordenada

O arcabouço de RFC 9954 trata cada combinação como um único NamedGroup opaco. Não há duas extensões independentes para a aplicação montar depois. Valores públicos ou ciphertexts de componentes são concatenados na ordem fixa do grupo; segredos de comprimento fixo também são concatenados e entram no lugar em que o TLS 1.3 usaria o segredo (EC)DHE convencional.

X25519MLKEM768, valor IANA 4588, começa com ML-KEM. O cliente envia 1.184 bytes da chave de encapsulamento ML-KEM-768 e 32 bytes X25519, totalizando 1.216. O servidor devolve 1.088 bytes de ciphertext ML-KEM e 32 bytes X25519, ou 1.120. O segredo traz 32 bytes ML-KEM e 32 bytes X25519 nessa ordem.

SecP256r1MLKEM768, valor 4587, começa com P-256. O cliente combina o ponto não comprimido de 65 bytes com a chave ML-KEM de 1.184 bytes; o servidor usa os mesmos 65 bytes e o ciphertext de 1.088. O segredo é ECDHE de 32 bytes seguido de ML-KEM de 32.

SecP384r1MLKEM1024, valor 4589, junta um ponto P-384 de 97 bytes a uma grandeza ML-KEM-1024 de 1.568 bytes. Os key shares de cliente e servidor têm 1.665 bytes. O segredo final contém 48 bytes ECDHE e 32 bytes ML-KEM.

Os comprimentos fixos tornam a concatenação inequívoca. Também mostram por que ordem e parâmetros fazem parte da segurança. Copiar o formato para outro protocolo sem o restante das regras não herda a análise.

O transcript mantém negociação e sessão na mesma história

O TLS 1.3 atual, em RFC 9846, incorpora ClientHello, eventual HelloRetryRequest, segundo ClientHello, ServerHello e mensagens de autenticação ao transcript. O key share selecionado pelo servidor alimenta o cronograma de chaves. CertificateVerify assina o transcript, e Finished comprova posse das chaves derivadas.

RFC 10024 afirma que sua análise de segurança depende de forma crucial desse transcript TLS. A concatenação isolada não é uma receita universal. O protocolo liga a oferta, a escolha, a autenticação e o resultado da sessão.

RFC 9794 fornece uma terminologia que reduz exageros. Um esquema híbrido PQ/T contém pelo menos um componente pós-quântico e um tradicional. “Pós-quântico” descreve uma propriedade pretendida; não elimina a possibilidade de um ataque clássico ou quântico futuro.

Por isso, o registro operacional deve unir grupos oferecidos, key shares enviados, HelloRetryRequest, grupo escolhido, validações, esquema de assinatura de CertificateVerify e conclusão de Finished. Uma tela que mostra “suporte habilitado” registra intenção, não execução.

As rejeições protegem valores, não o ambiente inteiro

RFC 10024 manda o servidor validar a chave de encapsulamento ML-KEM do cliente conforme FIPS 203 e abortar com illegal_parameter se a verificação falhar. O cliente confirma o comprimento do ciphertext. Os componentes ECDHE realizam suas validações; X25519 rejeita o segredo compartilhado todo zero. Outra falha de desencapsulamento ML-KEM produz internal_error.

São controles relevantes. Uma entrada inválida não pode virar uma sessão aparentemente legítima. Mas nenhum desses testes identifica a fonte do acaso, comprova resistência a canal lateral, verifica a memória compartilhada ou confirma que todos os pontos de presença executam o mesmo binário.

FIPS 203 padroniza ML-KEM-512, 768 e 1024 e o descreve como considerado seguro diante de adversários com computador quântico. A linguagem é calibrada: padronização não substitui implementação correta, parâmetros adequados, aleatoriedade e criptoanálise contínua.

NIST SP 800-227 apresenta recomendações mais amplas para o uso seguro de KEMs, inclusive combinações. Dizer que uma arquitetura “segue o NIST” não demonstra quais recomendações um módulo em produção efetivamente executa.

O RNG compartilhado é o caso que o próprio RFC escolheu

Na encapsulação ML-KEM, o servidor sorteia uma grandeza m; o cliente a recupera ao desencapsular. RFC 10024 observa que, se m revelar informação sobre outras saídas do gerador, essa informação chega ao cliente. O escalar efêmero ECDHE também depende de aleatoriedade criptograficamente segura, embora não seja enviado diretamente.

A consequência é explícita: se os dois algoritmos usam o mesmo RNG inseguro, a divulgação do estado por meio de um afeta a segurança do outro.

É incorreto apagar a palavra “inseguro”. Um CSPRNG corretamente projetado, semeado, re-semeado e protegido não quebra apenas por ser compartilhado. Também não existe uma exigência automática de dois equipamentos físicos. O que precisa ser conhecido é o caminho da entropia, a semente, a recuperação após fork ou snapshot, o reseeding, os testes de saúde, a exposição de memória e as saídas observáveis.

RFC 8937 explica como entropia inicial deficiente pode enfraquecer todas as instâncias originadas dela. Também propõe um invólucro opcional que mistura material derivado de uma operação de chave privada de longa duração para reforçar a aleatoriedade entre sessões. Essa é uma possível mitigação, não uma prova automática sobre qualquer implantação.

O mesmo raciocínio encontra outras raízes comuns. Uma vulnerabilidade de biblioteca pode atravessar os dois componentes. Um firmware de HSM pode controlar ambos. Uma cadeia de build comprometida pode substituí-los no mesmo release. Um único fornecedor de terminação pode mudar a política de toda a frota. Nada disso torna a combinação matemática defeituosa; apenas mostra que o domínio de falha operacional é maior do que o nome do algoritmo.

A ordem FIPS define uma obrigação estreita

RFC 10024 descreve uma condição NIST para entregar dois segredos distintos ao HKDF: o primeiro deve vir de um esquema de estabelecimento de chaves aprovado pelo FIPS. Nos grupos SecP256r1MLKEM768 e SecP384r1MLKEM1024, ECDHE vem primeiro; para o uso descrito, sua implementação deve ser certificada, enquanto essa condição de ordem não exige certificação da implementação ML-KEM. Em X25519MLKEM768, ML-KEM vem primeiro, e sua implementação assume a exigência.

Primeiro não significa mais forte. A certificação do componente exigido não certifica o outro, o RNG, o firmware, a negociação ou o serviço inteiro. A declaração precisa citar módulo, versão, certificado e o que ficou fora da fronteira.

O registro IANA não é recibo de produção

O registro IANA de TLS Supported Groups atribui 4587, 4588 e 4589 aos grupos finais. Somente X25519MLKEM768 tem Recommended Y; os grupos secp aparecem com N. A própria IANA ressalta que N não implica necessariamente falha: o uso pode ser limitado ou específico.

Os grupos Kyber experimentais 25497 e 25498 estão obsoletos e desencorajados. Uma telemetria que reduz ambos a “PQC” perde a diferença entre wire semantics de rascunho e padrão final.

O registro oferece um nome comum. A configuração revela intenção. ClientHello mostra a oferta. ServerHello e transcript comprovam a seleção de uma conexão. Só a medição da frota mostra cobertura.

A busca oficial de erratas do RFC 10024 não exibia registros em 30 de agosto de 2026. É uma observação datada, não uma garantia sobre todos os códigos e interpretações.

A assinatura do certificado continua em outra trilha

RFC 9954 exclui autenticação de nova geração do escopo. O TLS 1.3 separa a concordância de chaves das mensagens Certificate e CertificateVerify. Uma conexão pode negociar X25519MLKEM768 corretamente e ainda autenticar o servidor com uma assinatura tradicional.

A chave híbrida trata do risco de coletar hoje para decifrar depois. A falsificação futura e a migração de certificados têm outro cronograma. Um inventário honesto separa grupo negociado, assinatura, ponto de terminação e autorização da aplicação, em vez de comprimir tudo em “PQC concluído”.

A primazia do código em execução, de Heng Lu, estabelece a disciplina de evidência: transcript e resultado observado têm precedência sobre rótulos de configuração. A doutrina da especificação inicial mínima e decisão futura localizada explica por que o padrão fixa interoperabilidade sem decidir a topologia operacional de cada organização.

A leitura das camadas de realidade e do poder simbólico separa o símbolo “híbrido” das operações que ele representa. A análise do controle técnico e prático dos dados pergunta quem pode alterar terminador, biblioteca, entropia, telemetria e rollback. Esses poderes desenham a fronteira efetiva.

O módulo pode combinar os dois segredos sem erro. A organização ainda precisa provar que uma única raiz não decide o destino dos dois.