If you already have AES, why would you need a separate construction to encrypt an AES key? The answer is a good lesson in reading a specification’s motivation rather than its algorithm.
What is different about a key
A key is short, high-entropy, and its integrity matters absolutely. Encrypting one with a general-purpose mode brings problems that are invisible with a message:
- An IV to manage. Which means storing it, transmitting it, and never reusing it. Extra state around something that should be a single opaque blob.
- No integrity, unless you add it. CBC or CTR will happily decrypt a tampered ciphertext into a different key, and you will find out when a signature fails for reasons nobody can explain.
- Length leakage. Not a concern for a key of known size, but the padding you add to reach a block boundary is one more thing to get wrong.
What Key Wrap does instead
RFC 3394 defines a deterministic construction with no IV and built-in integrity. It uses a fixed initial value; if unwrapping does not produce it, the wrapped key was altered and the operation fails.
Deterministic is the point. The same key wrapped with the same wrapping key gives the same output every time, which is a property you want when comparing or deduplicating, and which is exactly what you must never do to a message.
RFC 5649 extends it to keys whose length is not a multiple of eight bytes, which is what makes it usable in practice.
Where you meet it
In JWE, under the names A128KW, A192KW and A256KW. The token’s content encryption key is wrapped with a key you and the recipient share, and the result is the second segment of the token. The JWE article covers the surrounding structure.
aes-key-wrap implements both RFCs in pure PHP.
The general lesson
When a specification exists for a task you could accomplish with a general tool, the interesting question is not « is it equivalent » but « what did they need that the general tool did not give ». Here it was: no IV to mishandle, and failure on tampering rather than a wrong key handed back silently.