Resumo

  • O RFC 10032 é uma publicação Informational do fluxo IRTF, baseada no consenso do CFRG, e não uma obrigação do Standards Track da IETF. As seis alocações da IANA estabilizam nomes, não impõem adoção.
  • O registro distingue AEGIS-128L, AEGIS-256 e quatro formas paralelas X2/X4, mas não codifica a escolha de tag de 128 ou 256 bits. Modos paralelos são opcionais e exigem acordo sobre a variante exata.
  • Um autoteste de biblioteca confirma resultados para vetores fixos. Não prova o que os pares negociaram, qual binário e caminho de CPU rodaram, como nonce e dados associados foram construídos ou qual suíte protegeu uma sessão.
  • Um recibo de custódia deve unir documento e registro, perfil de protocolo, seleção autenticada, código e tag, ciclos de chave e nonce, codificação dos dados associados, caminho de execução, testes, falhas, contadores, fallback e rollback.

O número termina onde a operação começa

A IANA atribui 32 a AEAD_AEGIS128L, 33 a AEAD_AEGIS256, 34 e 35 às formas AEGIS-128X2/X4 e 36 e 37 às AEGIS-256X2/X4. Esses números impedem que especificações incompatíveis usem o mesmo identificador público e permitem referências inequívocas.

Não são uma transcrição de sessão. O RFC 5116, origem da interface e do registro AEAD, declara que registrar um algoritmo não significa endossá-lo nem certificar sua segurança. A interface tampouco decide política antirreplay ou controle de acesso. Isso pertence ao protocolo chamador e à implantação.

O RFC 10032 define primitivas, parâmetros, orientações e vetores. Ele não estabelece uma negociação universal para TLS, IPsec, QUIC, armazenamento ou aplicações privadas. Cada perfil precisa decidir se oferece AEGIS, o significado do identificador, o tamanho da tag, a origem de chaves e nonces, os bytes de dados associados e a reação à falha de autenticação.

Logo, “a biblioteca expõe AEGIS” é uma afirmação de capacidade. “Esta sessão selecionou AEGIS-256X2 com estes parâmetros” é uma afirmação sobre acordo e execução. O registro não transforma a primeira na segunda.

O fluxo de publicação faz parte do fato

O RFC 10032 saiu em setembro de 2026 no fluxo IRTF como Informational. Ele registra consenso do CFRG, mas esclarece que não é produto nem padrão da IETF e que resultados do IRTF podem não ser adequados para implantação.

Isso descreve autoridade, não reduz o mérito do trabalho. O RFC 5743 explica a preparação pelo grupo de pesquisa, a revisão do IRSG e a verificação de conflito pelo IESG. O RFC 7841 distingue documentos de fluxos não IETF da revisão e aprovação ampla de um padrão IETF.

Há quatro fatos separados: consenso de pesquisa no CFRG, aprovação de publicação pelo IRSG, verificação de conflito pelo IESG e alocação única pela IANA. Nenhum deles demonstra adoção por um protocolo, ativação padrão num produto ou seleção por um par de endpoints.

Em 20 de setembro, a página pública da IANA exibia as seis linhas, embora a referência ainda apontasse para o draft 18 e a página informasse atualização em 7 de julho. Essa defasagem observada não invalida os códigos. Ela mostra por que uma revisão deve guardar, com data, tanto o estado de publicação quanto a tela do registro.

O tamanho da tag não está no código

AEGIS-128L usa chave e nonce de 128 bits; AEGIS-256 usa ambos de 256 bits. As duas famílias aceitam tags de autenticação de 128 ou 256 bits. Os nomes da IANA carregam família e, nas formas paralelas, grau X2/X4, mas não o tamanho da tag.

Essa escolha altera a alegação de segurança e o formato no fio. O RFC 10032 descreve cerca de 2^64 de trabalho de compromisso para a tag de 128 bits e cerca de 2^128 para a de 256 bits, no cenário definido no documento. Dois pares podem concordar com o código 32 e ainda esperar limites de tag diferentes.

O enquadramento também precisa ser fixado: ciphertext e tag podem seguir separados ou combinados, com a tag logo depois do ciphertext. “AEGIS-128L” não informa quantos bytes foram analisados nem onde ficou a fronteira.

Dados associados completam o perfil. O RFC 5116 cita endereços, portas, números de sequência e versões em claro. O RFC 10032 limita uma propriedade de compromisso completo ao caso em que o adversário não controla esses dados e oferece construções adicionais para exigências mais fortes. Lista de campos, ordem, tamanhos, versão e separação de domínio são evidência de protocolo.

Paralelismo é uma decisão de compatibilidade

AEGIS-128X e AEGIS-256X exploram registradores vetoriais largos e instruções AES vetoriais. X2 e X4 designam graus de paralelismo dois e quatro. O ganho real depende da arquitetura e da implementação.

O próprio RFC impõe prudência: um protocolo só deveria selecionar modo paralelo quando todas as partes concordarem com a variante específica. AEGIS-128L e AEGIS-256 devem permanecer como padrões, e implementações podem omitir as variantes paralelas.

Assim, um benchmark de X4 não cria uma suíte portátil. O par remoto pode ter apenas a forma base; o binário pode ter sido compilado sem X; uma migração de máquina virtual pode mudar o conjunto de instruções; o despachante em tempo de execução pode fazer fallback enquanto a configuração continua dizendo “AEGIS”.

São necessárias três evidências: a oferta e seleção do protocolo, a capacidade exata de cada par e o caminho realmente executado. Misturá-las em um indicador esconde onde a cadeia se rompeu.

A custódia do nonce continua necessária

No uso para cifragem, o RFC 10032 exige nonce único por chave, inclusive entre tamanhos de tag diferentes. Reutilização revela imediatamente a diferença bit a bit de duas mensagens. Nonces podem ser públicos ou previsíveis e vir de contadores ou geradores de período longo.

Para a família de 128 bits, nonces aleatórios podem cobrir até 2^48 mensagens por chave com a probabilidade de colisão citada, em torno de 2^-33. Para a família de 256 bits, o texto diz não haver limite aleatório prático. Isso não elimina a regra de unicidade nem o dever de demonstrar geração e contabilidade.

A implantação precisa definir domínio de unicidade, época de chave, persistência após reinício, fonte aleatória, divisão entre shards e detecção de restauração ou clone. Dois processos restaurados do mesmo snapshot podem reivindicar o próximo valor. O tamanho do campo não escolhe o dono.

Para a chave, registre geração ou derivação, contexto de protocolo, começo e fim da época, separação de usuários, identificador e descarte. A permissão para apagar uma chave efêmera após inicialização não prova que a implementação selecionada realizou essa limpeza.

Vetores não atravessam a fronteira do laboratório

O RFC fornece vetores extensos para a rodada AES, algoritmos base, X2/X4 e MAC. Eles detectam problemas de ordem de bytes, finalização, bloco parcial e geração de tag. Testes cruzados entre implementações também são valiosos.

Nos testes negativos, altere tag, campo de dados associados, nonce e grau paralelo e exija rejeição. Em falha, o RFC manda não liberar plaintext não verificado nem tags calculadas, sobrescrever o buffer decifrado e comparar tags em tempo constante. Um caminho acelerado que passa vetores positivos, mas expõe bytes antes da autenticação, não preserva o comportamento.

Ainda assim, o teste não prova que um handshake real ofereceu a suíte, que ambos autenticaram a seleção, que a biblioteca esperada foi carregada, que o caminho de hardware esteve ativo ou que o contador permaneceu na época planejada. Esses são fatos de execução.

As catorze partes do recibo

Este recibo é um controle editorial proposto por Daniel Kade, não um campo do RFC 10032 nem um certificado da IETF, IRTF, CFRG ou IANA.

Primeiro, identidade do documento, fluxo, categoria, instantâneos de publicação, erratas e registro. Segundo, protocolo chamador, versão, perfil e geração da configuração. Terceiro, oferta e seleção autenticadas ou prova equivalente do acordo.

Quarto, número e variante base, X2 ou X4. Quinto, tamanho da tag e enquadramento. Sexto, capacidade dos pares e comportamento sem suporte. Sétimo, origem, derivação, contexto, época, identificador e descarte de chave.

Oitavo, construção e persistência do nonce, domínio de unicidade, reinício e contador por chave. Nono, campos e serialização canônica dos dados associados. Décimo, build da biblioteca, caminho de CPU/vetor e fallback. Décimo primeiro, vetores, testes cruzados e casos negativos.

Décimo segundo, semântica de falha, supressão de plaintext, comparação em tempo constante e alertas. Décimo terceiro, vínculo com sessões ou pacotes delimitados e telemetria de uso. Décimo quarto, reserva, rejeição de downgrade, gatilhos de rollback, saída do conjunto compatível e prazo de retenção.

O registro não prova o handshake; o handshake não prova a persistência do nonce; o vetor não identifica o binário carregado; o pacote sem época de chave e regras de dados associados não explica por que deve ser aceito. O recibo impede que fatos diferentes desapareçam numa única palavra: “suportado”.

Fontes