Resumo

  • O RFC 3394 transformava n blocos de 64 bits em n+1 blocos cifrados; o registro de integridade atravessava seis passagens e virava o bloco inicial, não um padding colocado depois.
  • O unwrap só podia entregar os dados se o registro recuperado coincidisse com o valor inicial esperado. Esse recibo não provava identidade, autorização, frescor, custódia da KEK ou uso posterior.

A diferença de comprimento era a pista. Entravam n blocos e saíam n+1. O bloco adicional não ficava fora do mecanismo: circulava com a carga e depois guardava a saída.

Publicado em setembro de 2002 como Informational, o RFC levou a especificação AES Key Wrap do NIST ao registro da Internet. O texto reconheceu que a maior parte vinha do NIST e que as afirmações de segurança eram do governo americano. Seu trabalho era tornar a transformação reproduzível.

“Key data” podia significar uma chave, várias ou dados associados. A KEK usava 128, 192 ou 256 bits. A entrada era repartida em pelo menos dois blocos de 64 bits, e a saída acrescentava exatamente um.

Os blocos ocupavam R[1] a R[n]; A recebia um valor inicial. Seis passagens sobre o conjunto geravam 6n operações AES. Cada passo cifrava A | R[i]; a metade baixa substituía R[i], e a alta, combinada por XOR ao contador t, atualizava A.

Ao final, A virava C[0]. Não era enchimento posterior, mas estado misturado com cada bloco e posição. Alteração, KEK errada, ordem trocada ou contrato IV distinto deveria impedir a volta ao início esperado.

O unwrap revertia passos e contadores. Os registros obtidos ainda eram candidatos: só uma comparação válida de A autorizava sua liberação. Falha exigia erro e proibia retornar qualquer dado de chave. O limite dependia de o software cumprir essa regra.

O IV padrão repetia A6 em 64 bits. O RFC associava a coincidência a uma chance 2^-64 de corrupção, sob as hipóteses do algoritmo. Não era taxa operacional, assinatura de pessoa nem prova de que o sistema guardou seus segredos.

Aceitação demonstrava coerência entre ciphertext, KEK, variante e IV. Não identificava quem envolveu, não autorizava, não dava frescor, não provava que a KEK não vazou e não garantia que a chave servisse ao próximo componente. Uma KEK comprometida produz pacotes perfeitamente aceitos.

Vetores de teste também têm autoridade estreita. Eles comprovam uma transformação de bytes, não canais laterais, isolamento ou manuseio em produção. O RFC alertou que a perda da KEK podia expor tudo que ela protegia.

O domínio original exigia n >= 2 e comprimentos múltiplos de 64 bits. Valores iniciais alternativos foram previstos para outras extensões de integridade e outros comprimentos. Era uma superfície de evolução, não uma exceção implícita.

O RFC 5649 usou essa superfície no Key Wrap with Padding. Seu AIV junta constante e indicador de comprimento de 32 bits; o unwrap valida ambos e os zeros de padding, com caso especial para um bloco. Nova afirmação de comprimento exigiu novo recibo.

RFC 3565, JOSE e COSE acrescentaram identificadores em seus recipientes. Eles selecionam variante e tamanho, mas não tornam A uma identidade nem confundem KW com KWP. As erratas, por sua vez, corrigem redação, índices e referência sem alterar seis passagens ou a porta de liberação.

A especificação inicial mínima de Lu Heng explica a economia: blocos, estado, contador, passagens, IV e erro bastavam à interoperabilidade; custódia e autorização ficavam nos sistemas responsáveis. A primazia do código em execução exige evidência de que a implementação realmente segura os bytes quando o teste falha.

O registro extra decidia quando bytes candidatos viravam chave liberada. Seu poder terminava ali. Ele confirmava a forma criptográfica interna, não quem merecia o conteúdo nem o resultado após a abertura.

Fontes