Summary

  • RFC 3394 wrapped n 64-bit key-data blocks into n+1 ciphertext blocks by mixing a separate integrity register through six passes; the extra leading block was transformed state, not passive padding.
  • Unwrap could return key data only if the recovered register matched the expected initial value. That receipt checked the cryptographic package, but did not identify a sender, prove authorization or custody, provide freshness, or show that the released key later worked.

A parcel grows when it is packed. That extra space usually looks like wrapping material: useful for shape, irrelevant to identity. RFC 3394 made its extra block do something more consequential. The block travelled through the machinery with the cargo, then stood at the exit as the condition for releasing it.

Published in September 2002 as an Informational RFC, the document carried the AES Key Wrap algorithm from a NIST specification into the Internet standards record. It was unusually candid about provenance: most of the text came from the NIST work, and the security assertions were attributed to the United States Government rather than to the RFC authors. The document supplied a reproducible transform, not a claim of independent cryptographic discovery.

The input called “key data” was broader than one AES key. It could contain a key, several keys or associated information. A key-encryption key, or KEK, could use any AES key size: 128, 192 or 256 bits. The data to be protected was divided into n blocks of 64 bits, with n at least two. The output contained n+1 such blocks.

That expansion came from the state design. The plaintext blocks entered registers R[1] through R[n]. A separate 64-bit register A began with an initial value. The algorithm made six passes over the R array, for 6n AES operations in total. At each step, it encrypted the 128-bit concatenation of A and one R block. The lower half replaced that data register. The upper half, XORed with the step counter t, became the new A.

After the last pass, the final A became ciphertext block C[0]; the transformed R registers followed it. The leading block was therefore not bytes added after encryption to fill a length. It had been mixed with every data block and every counter position. Alter a wrapped block, use the wrong KEK, choose a different initial-value contract or disturb the ordering, and the inverse process should fail to recover the expected start state.

Unwrap ran the transformation backwards. It began with C[0] in A, reversed the counters and AES operations, and produced candidate plaintext registers. Those candidates were not yet a key that the caller was entitled to receive. The implementation first compared the recovered A with an appropriate initial value. A match allowed the R values to cross the boundary. A mismatch required an error and, in the RFC’s mandatory language, no key data could be returned.

The default initial value was the repeated hexadecimal byte A6, filling all 64 bits. RFC 3394 said that if unwrap produced that value, the chance of corrupt key data was 2^-64; any other value had to be rejected. The figure described the integrity check under the transform’s security assumptions. It was not an observed incident frequency, a sender reputation or proof that the wrapping system around it had been implemented safely.

This distinction matters because acceptance answers a narrow question. It says that the ciphertext, KEK, algorithm and expected initial value were mutually consistent to the stated cryptographic strength. With a symmetric KEK, it does not identify which human or process produced the ciphertext. It does not show that wrapping was authorized, that the package is fresh rather than replayed, that the KEK was never copied, or that the recovered bytes belong to the algorithm and purpose the next component expects.

RFC 3394 itself warned about the largest authority outside the register: KEK custody. Compromise of a KEK could disclose every item protected under it. The A check cannot testify that the KEK remained secret, because the same compromised key can produce perfectly acceptable wraps. Nor can a successful test vector prove side-channel resistance, isolation, error uniformity or production key handling. A vector proves the specified byte transform for that case.

The input boundary was equally deliberate. The original construction required at least two 64-bit data blocks and accepted only lengths that were multiples of 64 bits. The document anticipated that key-management systems might need other integrity scopes and other lengths, so it reserved room for alternative initial values. Generic implementations were expected to be flexible about how those values were set and tested.

RFC 5649 later used that opening instead of pretending the old boundary did not exist. AES Key Wrap with Padding accepted data from one octet upward. Its alternative initial value joined a 32-bit constant to a 32-bit message-length indicator. Unwrap checked the constant, whether the length was plausible for the number of padded blocks, and whether padding octets were zero. A special one-block case covered short inputs. The later design changed the receipt because it changed the claim.

That evolution reveals why A was an architectural surface, not a magic constant. In the original form it said, in effect, that the fixed-length block sequence survived wrapping under the selected KEK. In the padded form it also carried a length assertion. Different initial-value structures could support different application contracts. Treating all of them as interchangeable “AES wrap” would erase the very evidence that the register was designed to preserve.

Later protocols added their own naming layers. RFC 3565 assigned CMS identifiers for AES key wrapping. JOSE and COSE eventually defined AES-KW algorithm families in web and CBOR containers. Those identifiers tell a parser which transform and key size to invoke within a protocol. They do not broaden the core register into an identity system or make old and padded variants interchangeable.

The errata record reinforces the difference between a stable mechanism and its printed notation. Verified corrections repair wording and array subscripts; held items clarify indexes and a dead historical link. They matter to faithful implementation and citation, but they do not replace six passes with another algorithm or move the release boundary. Reading the corrected record is part of reproducing the same transform.

Lu Heng’s Minimum Initial Specification principle explains the economy. RFC 3394 fixed the minimum machinery needed for independent implementations to produce and reverse the same protected sequence: block size, state, counter, passes, initial-value check and failure rule. It left key custody, authorization and protocol binding to the systems that actually possessed those authorities.

Running-Code Primacy supplies the final burden. A registered algorithm and passing example cannot prove that a deployed implementation withholds plaintext on failure, protects its KEK, avoids leakage or binds the result to the intended purpose. Those claims require observations of the running system. The standard makes the expected receipt exact; operations must prove that the receipt controls a real gate.

RFC 3394’s extra register was small enough to be mistaken for overhead. In fact it carried the difference between candidate bytes and a released key. Yet its authority ended at that boundary. It could say that the cryptographic package came back into the expected shape. It could not say who deserved the contents, whether the wrapping key was still trustworthy, or what happened after the gate opened.

Sources