Resumo

  • A RFC 9771 distribui os adjetivos comuns do AEAD por quatro famílias; confundi-las pode tornar enganosa, no limite do sistema, uma frase verdadeira sobre o algoritmo.
  • Uma decisão defensável exige um recibo de propriedade que conecte noção formal, construção e versão, comportamento da API, testes negativos, ciclo de chaves e integração do protocolo.

O adjetivo nunca foi a garantia

“Criptografia autenticada” soa como uma decisão de segurança encerrada. É, na verdade, uma primitiva cuja proteção depende de um contrato entre algoritmo, disciplina de chaves e nonces, dados associados, interface e estado do protocolo. Publicada em maio de 2025 pelo Crypto Forum Research Group da IRTF, a RFC 9771 importa por se recusar a reduzir esse contrato a um único selo de qualidade.

O documento é Informational: não é um padrão da Internet nem certifica aptidão para implantação. Sua força é taxonômica. Ele separa a segurança convencional de propriedades que resistem a capacidades adicionais do adversário; depois distingue ambas das propriedades de implementação e das funcionalidades que alteram a interface. Comprador, revisor e operador podem primeiro identificar o tipo de frase e só então decidir que prova ela requer.

A interface convencional da RFC 5116 recebe chave, nonce, dados associados e texto claro; a decifragem entrega texto ou falha. Ela já esconde uma obrigação operacional: cada chamada sob uma chave precisa de nonce único. Uma ficha dizendo “AES-GCM” não revela quem garante a unicidade, se ela resiste à restauração de snapshot, como emissores concorrentes dividem o espaço ou se acelerador e fallback compartilham estado.

A RFC 9771 amplia o vocabulário sem eliminar essas perguntas. Não é um cardápio em que mais adjetivos significam automaticamente mais proteção, mas um mapa de obrigações de prova diferentes.

Quatro famílias, quatro conjuntos de evidências

Família O que muda Evidência necessária
Segurança convencional Confidencialidade e integridade básicas Construção, parâmetros, noção formal, limites concretos, vetores e teto de uso
Propriedade adicional de segurança Adversário ganha repetição de nonce, multiusuário, vazamento ou texto antecipado Confidencialidade/integridade separadas, noção, não equivalências e testes de mau uso
Propriedade de implementação Como o cálculo é executado Caminho medido, memória e passagens, fronteira de verificação, paridade entre hardware e fallback
Funcionalidade adicional Nova interface, como atualização ou expansão escolhida Contrato de API, noção revisada, transições, compatibilidade e semântica de falha

A divisão expõe um erro frequente. “Uma passagem”, “paralelizável” e “processável em fluxo” descrevem computação; não provam confidencialidade nem integridade. A RFC 9771 observa que uma construção em fluxo pode precisar de segurança por blocos e integridade quando texto não verificado é liberado. Benchmark de vazão não é recibo de segurança de uma API de streaming.

O erro inverso também ocorre. Um resultado formal sobre a construção não demonstra que o wrapper o preserve. Se o decifrador entrega bytes antes de verificar a tag, a aplicação entra no cenário RUP, de liberação de texto não verificado. A confidencialidade convencional se torna impossível e os objetivos relevantes mudam. Duas APIs com a mesma primitiva — uma em buffer, outra incremental — podem sustentar alegações materialmente diferentes.

As funcionalidades adicionais tornam a fronteira ainda mais clara. A RFC 9771 coloca criptografia autenticada incremental e robusta em apêndice porque exigem interfaces além do AEAD convencional. Na robusta, quem chama escolhe a expansão do texto cifrado, trocando comprimento pela melhor integridade disponível naquele tamanho. “Robusta” aqui não significa “robustez de chave”, expressão às vezes usada como sinônimo de comprometimento de chave. Um registro que guarda só a palavra já perdeu a distinção importante.

Quase sinônimos escondem premissas

Resiliência e resistência ao mau uso de nonce parecem equivalentes; não são. Resiliência protege mensagens com nonce novo mesmo quando um adversário causa repetição em outro ponto. Resistência protege também mensagens que reutilizaram nonce, exceto o vazamento inevitável quando o mesmo texto se repete sob o mesmo nonce. Resistência implica resiliência, não o contrário.

Isso altera o plano de testes. Na resiliência, prova-se que um incidente não contamina tráfego fresco. Na resistência, também se caracteriza o tráfego afetado. AES-GCM-SIV na RFC 8452 é uma construção padronizada resistente a mau uso; a propriedade não se transfere ao GCM comum nem comprova o tratamento de chaves e erros pela integração.

Comprometimento tem armadilha semelhante. O de chave pergunta se um texto cifrado é válido sob chaves diferentes. O completo inclui nonce, dados associados e texto claro. O completo implica o de chave, não o inverso. A diferença importa quando a aplicação usa a decifragem bem-sucedida para descobrir conta, locatário ou contexto. A pesquisa sobre descoberta de contexto mostra que a ambiguidade entre contextos válidos é concreta. Ainda assim, o recibo precisa nomear construção, codificação do contexto, tamanho da tag e noção formal: uma palavra não vincula o que não foi codificado.

Do enunciado ao recibo de propriedade

O recibo é um objeto compacto, versionado e legível por compras, segurança, operações e resposta a incidentes. Começa pela propriedade exata e sua família na RFC 9771. “Confidencialidade e integridade resistentes a mau uso de nonce” é alegação; “nonces mais seguros” é marketing. Se confidencialidade e integridade usam noções diferentes, ambas aparecem. Uma noção alternativa exige prova de equivalência ou declaração de que não é equivalente.

Depois o recibo congela o objeto: algoritmo e construção, parâmetros, tamanho de tag, provedor ou biblioteca, versão e build, caminho de CPU ou acelerador e fallback. Prova do projeto e teste do binário respondem a perguntas diferentes; os dois são necessários.

A parte da interface registra entradas, momento de liberar saída, fronteira de verificação, ordem de blocos, cancelamento e erros. Atribui responsabilidade por nonce e dados associados. Saber se uma falha não produz saída, entrega buffer, libera parte do texto ou surge depois de o chamador agir determina o modelo real.

Testes negativos devem nascer da propriedade: nonce repetido, chave errada, dados associados alterados, texto de outro contexto, tag truncada ou forjada, blocos reordenados, saída precoce, rollback, restauração, fim do contador, mudança de fase e divergência entre software e offload. Teste observa comportamento; não substitui prova. Prova não mostra que a API respeitou as premissas.

O ciclo de chaves cobre geração e derivação, identidade, escopo de nonce e sequência, concorrência, tetos, rotação, destruição, backup, restauração e agregação multiusuário. A RFC 8645 descreve mecanismos de troca, mas a implantação precisa mostrar o gatilho escolhido e a sobreposição de estados. Mudanças de versão, acelerador, alocador de nonce, persistência ou política devem expirar o recibo.

Por fim, a integração do protocolo fornece evidência entre primitiva e rede. O TLS 1.3 constrói nonces de registros a partir de sequências; o QUIC acrescenta número de pacote e fase de chave. Retentativas, replay, recuperação, migração, enquadramento, vínculo de contexto, interoperabilidade e terminação em hardware precisam de verificação própria.

O que o comprador já pode exigir

A RFC 9771 permite pedir: “Para cada propriedade AEAD não convencional alegada, entregue a noção exata, a implementação e versão a que se aplica, o comportamento da API que preserva suas premissas, os testes negativos de fronteira, os controles do ciclo de chaves e os caminhos de protocolo cobertos”.

“Não suportado”, “somente neste caminho” ou “não provado neste modo de falha” são respostas úteis: criam uma fronteira que pode ser precificada, monitorada e revista. Perigoso é o nome sem responsável nem validade, pois transforma resultado condicional em memória institucional permanente.

Fontes