Resumo

  • RFC 5297 preserva autenticidade quando um nonce é reutilizado, mas permite observar se o mesmo texto claro e os mesmos dados associados voltaram sob a mesma chave e nonce.
  • A contenção não elimina a regra de unicidade nem prova que o chamador escolheu o modo correto, manteve o vetor AD ou reteve o claro até a autenticação.

O erro ficou menor, não virou política

SIV produz seu vetor de inicialização a partir da própria afirmação protegida. S2V usa CMAC sobre uma sequência de dados associados e sobre o texto claro. O resultado de 128 bits alimenta AES-CTR; a saída reúne esse vetor sintético e um cifrado do mesmo tamanho do claro.

Quando o nonce não se repete, valem as propriedades usuais descritas no RFC. Se ele se repete, a autenticidade continua: fabricar outra entrada que não retorne FAIL permanece fora do alcance esperado do atacante. A privacidade, porém, perde a ocultação da igualdade. Mesmo claro, mesmos dados associados, mesma chave e mesmo nonce deixam a mesma marca.

Essa marca pode revelar que uma instrução reapareceu, que uma autorização não mudou, que dois destinatários receberam o mesmo objeto ou que um evento binário voltou a ocorrer. O incidente não deve ser registrado como “sem impacto” só porque nenhum bit foi lido diretamente e nenhuma falsificação passou.

O próprio conceito de nonce exclui a reutilização. A resistência existe para quando a disciplina falha. O RFC 8452, em outra construção posterior, explicita a mesma orientação: oferecer a melhor segurança possível diante da repetição não é recomendar repetição intencional.

Uma implementação, duas intenções

No modo com nonce, ele ocupa o último componente de dados associados antes do claro. Componentes anteriores podem vincular conta, objeto, versão, finalidade e destinatário. Se aleatório, o nonce deveria ter pelo menos 128 bits e vir de uma fonte com 128 bits de entropia; contador e tempo também são possíveis quando o protocolo governa sua unicidade.

No modo determinístico não há componente nonce. O caso clássico é envolver uma chave criptográfica, cujo valor é imprevisível para o adversário. Dados associados ainda podem amarrar o envelope a um uso ou receptor.

O mesmo formato de saída não demonstra qual intenção foi autorizada. Uma equipe pode interpretar a ausência de nonce como key wrap legítimo; outra pode ter retirado o nonce de dados previsíveis apenas para evitar persistência. O recibo precisa carregar o perfil, o modo, a autorização e a justificativa de imprevisibilidade quando ela for requisito.

O vetor AD é uma estrutura

S2V recebe um vetor de strings distintas e variáveis. Posição e fronteira fazem parte da autenticação. conta=ab mais tipo=c não pode colidir semanticamente com conta=a mais tipo=bc. Trocar versão e finalidade também muda a declaração.

O RFC 5116 oferece apenas um bloco AD. Uma ponte para SIV deve serializar o vetor sem ambiguidade, incluindo comprimentos, tipos e versão do esquema. Um tag válido confirma a cadeia de bytes. Não confirma que produtor e consumidor dividiram essa cadeia nos mesmos campos ou atribuíram a ela o mesmo sentido.

Há ainda um teto: S2V aceita até 127 componentes totais; o claro usa um, restando 126 para AD. Juntar, omitir ou reordenar campos silenciosamente para caber não preserva a chamada original.

Primeiro verificar, depois dar efeito

Na decriptação, CTR gera um claro candidato. S2V é recalculado sobre esse candidato e o mesmo vetor AD. Só a igualdade com o vetor recebido permite devolver o claro; caso contrário, o resultado é FAIL.

Um wrapper pode romper essa fronteira sem alterar a primitiva. Se o candidato entra em parser, log, cache ou regra antes da comparação, o fracasso posterior não apaga o efeito. Vetores de teste aprovados não comprovam a quarentena da interface.

Os eventos operacionais devem separar início, candidato isolado, comparação, autenticação aprovada, liberação, validação de formato, autorização e efeito final. “Decrypt OK” não substitui essa cadeia.

Três números não contam a história

IANA reserva 15, 16 e 17 para as variantes AES-SIV-CMAC. A tabela coordena o identificador. Ela não observa algoritmo efetivo, geração e divisão da chave, modo, nonce, esquema AD, liberação ou resultado do aplicativo.

O RFC 5297 também trata do volume de chamadas sob uma chave e recomenda prudência em torno de 2^48 invocações distintas, seguindo CMAC. Esse orçamento não é o contador de nonces. Uma operação pode respeitar um e violar o outro.

O recibo não secreto junta algoritmo e build; identidade e geração da chave; modo; nomes e hashes ordenados de AD; origem e veredito de unicidade do nonce; identidade controlada do objeto; hash do vetor sintético; autenticação; liberação; tupla repetida; avaliação de igualdade; aceitação posterior; e orçamento por chave.

Sources