Resumo

  • O RFC 10032 especifica AEGIS como criptografia autenticada, gerador de fluxo e código de autenticação de mensagem. A criptografia exige unicidade de (chave, nonce) e bloqueio do texto até a verificação; o fluxo descarta a tag; somente o MAC permite reutilizar o par com entradas diferentes.
  • Um identificador IANA, um vetor correto ou uma medição de velocidade não prova o papel efetivamente chamado. A evidência precisa registrar finalidade da chave, domínio de nonce, dados associados, caminho de execução e a fronteira que impediu bytes não verificados de produzir efeitos.

O RFC 10032 foi publicado em setembro de 2026 como RFC Informational no fluxo da IRTF, registrando consenso do CFRG. Não é um padrão do Standards Track da IETF. Ele descreve AEGIS-128L, AEGIS-256, AEGIS-128X e AEGIS-256X, todos construídos com a função de rodada de criptografia do AES.

Os modos X aproveitam registradores vetoriais largos e instruções AES vetoriais. Essa capacidade pode explicar uma escolha de desempenho, mas não prova que um protocolo a negociou, que o binário carregado a utilizou ou que o aplicativo preservou as condições de segurança.

A IANA atribuiu os números AEAD 32 a 37 às variantes de base e às formas X2 e X4. Esses números coordenam nomes. Não codificam o papel AEAD, fluxo ou MAC; não escolhem tag de 128 ou 256 bits; não descrevem dados associados; não provam alocação de nonce nem comportamento em falha.

O artigo já publicado sobre RFC 10032 na BTW possui a fronteira entre codepoint e recibo de negociação. Aqui o objeto é outro: depois que a família foi escolhida, qual das três funções foi chamada, e que autoridade sua saída realmente possui?

AEAD exige uma barreira antes do texto claro

No papel AEAD, a criptografia recebe mensagem, dados associados, chave e nonce e produz texto cifrado e tag. A descriptografia calcula a tag esperada, compara em tempo constante e só entrega texto claro quando a verificação passa.

O par chave-nonce deve ser único para criptografia. Alterar o tamanho da tag não abre outro espaço de nonce. Reutilizar o par revela a diferença bit a bit de duas mensagens e permite recuperar o estado interno no cenário descrito. O nonce pode ser público e previsível; sua obrigação central é não se repetir sob a mesma chave.

O RFC fornece limites para geração aleatória. AEGIS-128L e AEGIS-128X podem cobrir até 2^48 mensagens sob uma chave com probabilidade de colisão próxima de 2^-33. Para AEGIS-256 e AEGIS-256X, a análise não encontra limite prático. Isso não é autorização para repetir um valor; é uma avaliação de colisões quando a geração aleatória está correta.

A segunda obrigação está na saída. Se a tag falha, o texto provisório e a tag calculada não podem ser devolvidos, e o buffer de texto deve ser sobrescrito. Entregar alguns bytes a um parser, callback, log ou banco antes da decisão cria uma fuga mesmo que a função termine com erro.

Um recibo operacional deve, portanto, ligar papel, variante, tamanho da tag, identidade da chave, evento de nonce, codificação inequívoca dos dados associados, resultado de verificação e qualquer efeito antecipado. A tag autentica uma tupla de bits sob uma chave; ela não controla a arquitetura que talvez já tenha agido.

O fluxo abandona a autenticação de propósito

Para gerar fluxo, o RFC manda criptografar uma mensagem de zeros sem dados associados e descartar a tag. A implementação pode omitir a finalização. O resultado é um fluxo de chave, não uma mensagem autenticada.

Essa função é legítima dentro de uma construção que conhece sua natureza. O erro é deixar o nome AEGIS emprestar a reputação do AEAD. Um painel exibe “protegido por AEGIS”; uma API devolve bytes sem tipo; uma equipe posterior imagina que a tag fica em outra camada. Não fica: ela foi descartada por definição.

O fluxo precisa de finalidade de chave e espaço de nonce próprios, além de um tipo explícito de “fluxo não autenticado”. Se outra construção fornece integridade, o registro deve nomeá-la, indicar a ordem das operações e provar que o texto não foi liberado antes dessa verificação.

O MAC possui a única exceção de reúso

O MAC absorve dados e produz tag de 128 ou 256 bits. O RFC 10032 diz que esta é a única função que permite reutilizar (chave, nonce) com entradas diferentes.

O sujeito da exceção é a função MAC, não a marca AEGIS. Uma política única de nonce pode transportar essa licença para a criptografia. O núcleo continuará calculando e não saberá que recebeu autoridade errada.

A tag MAC também tem limites negativos. Ela não pode servir como hash quando a chave é conhecida, pois é possível construir entradas com colisão de estado. Não pode alimentar derivação de chave, porque não há garantia de distribuição uniforme. O formato de 128 ou 256 bits não a transforma em resumo de conteúdo nem em novo segredo.

A separação deve ser executável: IDs de chave vinculados a AEAD, STREAM ou MAC; rótulos de derivação diferentes; alocadores de nonce independentes; rejeição de uma chave em papel incompatível. Uma observação na documentação não é controle.

Tag e dados associados continuam sendo escolhas de protocolo

Com tag de 128 bits, o RFC descreve cerca de 64 bits de segurança de comprometimento de chave no jogo considerado; com 256 bits, cerca de 128. O codepoint não informa qual foi usada.

O comprometimento também depende de quem controla os dados associados. AEGIS é plenamente comprometedor no caso restrito em que o adversário não os controla. Quando ele pode alterá-los, a análise citada permite encontrar eficientemente várias chaves que verificam o mesmo texto autenticado. Um protocolo que exige propriedade mais forte pode aplicar uma função resistente a colisão e preimagem aos dados associados ou vinculá-los, com codificação inequívoca, ao campo info de uma KDF conforme as condições registradas.

Essas são decisões da construção superior. O protocolo deve dizer quais campos entram, como são serializados, quem os controla e qual compromisso precisa. A primitiva autentica os bits recebidos, não o significado que a organização atribui a eles.

Vetores não alcançam a custódia

Os vetores extensos do RFC demonstram correspondência de uma implementação para entradas fixas. Testes cruzados demonstram acordo entre implementações. Nenhum deles mostra que a produção chamou o papel correto ou conteve a falha.

Testes negativos devem provocar confusão: oferecer a chave de um papel a outro; repetir nonce de criptografia mudando a tag; garantir que a exceção MAC não altere o alocador AEAD; exigir que o fluxo seja marcado como não autenticado; corromper texto, tag e dados associados e observar ausência de texto, callback e efeito; enviar tag MAC a hash e KDF e esperar rejeição; confirmar binário e caminho de CPU; separar contadores por função.

A segurança contra tempo, potência e injeção de falhas depende do AESRound executado e do modelo de ameaça. A possibilidade de apagar chaves efêmeras após a inicialização não prova que compilador e biblioteca o fizeram. Isso exige evidência do código em execução.

O recibo mínimo reúne propósito e ameaça, papel, variante e paralelismo, tag, chave e finalidade, namespace e alocação de nonce, esquema de dados associados, versão e caminho da biblioteca, verificação e limpeza, barreira de saída, contadores e decisão final do aplicativo.

A doutrina de especificação mínima de Lu Heng permite uma primitiva comum sem transformar o registro em soberano sobre o uso. O registro nomeia; a biblioteca executa; o protocolo estrutura; o aplicativo autoriza a consequência. A disciplina das camadas de realidade impede que publicação, teste ou tag tome emprestado o poder da camada seguinte.

O aprendizado operacional do RFC 10032 é que compartilhar a mecânica não funde os deveres. A cifra manteve o nome. A organização precisa manter separados os recibos.

Fontes