Resumo

  • A revisão 08 de draft-ietf-tcpm-tcp-ao-algs, publicada em 1º de outubro, esclarece que KMAC256-KDF segue a variante KMAC# de NIST SP 800-56C Revision 2, cujo contrato não deve ser reduzido ao nome genérico KMAC256 de SP 800-185.
  • Para provar interoperabilidade, o operador precisa associar a configuração aos parâmetros públicos, às codificações, ao vetor conhecido, aos bytes da opção TCP-AO e ao resultado observado no outro extremo.

Um painel pode contar dez mil sessões configuradas para KMAC256 e ainda não responder à pergunta decisiva: os dois lados executam a mesma função? A métrica mede um texto de configuração. Ela não mede a montagem dos argumentos nem o resultado intermediário usado como Traffic Key.

Esse intervalo ficou explícito na revisão 08 do projeto TCPM. O documento afirma que KMAC256 e seus argumentos surgem em NIST SP 800-185, enquanto SP 800-56C Revision 2 define a variante KMAC# com conjunto diferente de argumentos. Para o KDF proposto em TCP-AO, a conformidade é com KMAC#. A revisão também explica que o contador 1, inteiro de 32 bits em ordem de rede, representa a versão de KMAC256-KDF.

O texto é trabalho em andamento. Trata-se de um Internet-Draft com intenção Standards Track, não de RFC. A meta do grupo TCPM prevê envio ao IESG em novembro de 2026, mas uma meta não é decisão. No registro IANA consultado, os algoritmos TCP-AO continuam sendo SHA1 e AES128. HMAC-SHA256-128 e KMAC256-128 aparecem como ações solicitadas pelo projeto.

O KDF especificado combina um salt de 132 bytes zero, o contador em ordem de rede, a Master Key em Z, o contexto TCP-AO em FixedInfo, saída de 256 bits e a personalização ASCII KDF. A saída desejada tem exatamente o tamanho do bloco, portanto uma única invocação gera a Traffic Key.

O MAC subsequente usa outra instância. A Traffic Key de 256 bits vira a chave de KMAC256-128; a mensagem é construída segundo RFC 5925; a personalização é vazia; e a saída solicitada já tem 128 bits. O resultado de 16 bytes faz a opção TCP-AO completa consumir 20 dos 40 bytes disponíveis para opções TCP. Misturar a personalização KDF com a personalização vazia altera o contrato.

RFC 5925 torna o contexto dependente da conexão e da direção. Endereços, portas e números de sequência iniciais entram no cálculo. Em um SYN sem ACK, o número inicial ainda desconhecido do destino é zero. Depois, o par conhecido é usado. Um erro de sentido em FixedInfo pode parecer um problema de chave, embora a Master Key seja a mesma nos dois equipamentos.

A captura de pacotes ajuda, mas não declara o algoritmo. A opção leva Kind, Length, KeyID, RNextKeyID e MAC. O vínculo entre KeyID, KDF, MAC e Master Key fica no Master Key Tuple, configurado fora da opção. Dois lados podem transmitir o mesmo número de KeyID e atribuir a ele contratos locais diferentes.

Por isso, BTW propõe um recibo de instância de algoritmo. Ele identifica a revisão do projeto, os IDs de KDF e MAC, as versões NIST, salt, contador, ordem de bytes, comprimentos, personalizações, identidade não secreta da MKT, produto e build. Um hash do vetor conhecido liga a implementação ao cálculo reproduzido. Os bytes capturados, o resultado de verificação, o estado TCP e o evento da aplicação completam a cadeia.

O recibo exclui Master Key e Traffic Key de produção. Observabilidade não deve criar um vazamento. Identificadores de configuração, vetores públicos e ambientes com chaves de teste permitem comparação suficiente para diagnóstico sem expor material operacional.

Os anexos do projeto já incluem vetores KMAC para IPv4 e IPv6, com e sem cobertura das demais opções TCP. Passar por um vetor demonstra uma função para aquela entrada. Não confirma a MKT instalada no site, o sentido do contexto ou o conteúdo autenticado na sessão real. A validade de um vetor e a saúde de uma sessão são camadas relacionadas, não equivalentes.

O mesmo vale para os resultados posteriores. Uma capacidade anunciada não é vetor aprovado. Vetor aprovado não é segmento aceito. Segmento aceito não é conexão estável. Conexão estável não é política BGP correta nem serviço entregue. Um sistema de evidência deve permitir subir essa escada sem apagar os degraus.

Minimum Initial Specification, na formulação de Heng Lu, explica o limite. O núcleo compartilhado pode ser pequeno, mas deve ser estrito em tudo que determina a interoperabilidade: variante, papéis dos argumentos, codificações, contexto e tamanhos. Biblioteca e operação permanecem locais; o resultado matemático comum não pode depender de interpretação local.

Running-Code Primacy privilegia o que uma implementação reproduz e o que um par aceita. Reality Layers separa documento, registro, configuração, derivação, autenticação, conexão e aplicação. Daniel Kade usa essas ideias como lente editorial; elas não são apresentadas como posição do IETF ou do NIST.

O limite negativo é igualmente relevante. A revisão 08 não anuncia quebra de KMAC, não prova divergência em revisão 07 e não identifica produto incorreto. A revisão anterior do Security Directorate discutiu utilidade, tamanhos e espaço de opções, mas as fontes públicas não demonstram que ela causou a nova frase.

O ganho real da revisão é tornar auditável uma frase de compatibilidade. KMAC256 sozinho é um índice. A instância com parâmetros, vetor e bytes é o objeto operacional. Só o segundo permite distinguir biblioteca errada, contexto errado, chave errada, rejeição de segmento e falha da aplicação.

Fontes