Key wrapping and key exchange: moving keys without ever exposing them

"Get a key from A to B safely" sounds like one problem, but production systems actually face three distinct versions of it, and reaching for the wrong tool is a common real-world mistake. Wrapping a key with a symmetric KEK you already share with the recipient is one tool. Transporting a key to someone you've never shared a secret with, using their public key, is a different tool. Agreeing on a fresh shared secret with someone, without ever transmitting a key at all, is a third tool entirely — and it's the Diffie-Hellman idea from earlier in this catalog, applied at the systems level.

RFC 3394's AES Key Wrap (AES-KW) is deliberately not "just AES-GCM applied to a key" — it's a dedicated construction built around the fact that key material is already high-entropy, fixed in size, and never reused as wrapping input the way ordinary plaintext might be reused. AES-KW runs the key through six rounds of an AES-based transformation together with a fixed 64-bit integrity-check value (0xA6A6A6A6A6A6A6A6), so unwrapping with the wrong KEK fails loudly and immediately rather than silently returning garbage.

The practical result: AES-KW adds exactly 8 bytes of overhead to whatever it wraps, no matter the key size, and needs no IV or nonce at all — one of the few symmetric constructions in this catalog that's fully deterministic by design, because the input (a key) is guaranteed to already be unpredictable.

"Import Key Material" flows — used when bringing an existing key into a cloud KMS, or moving one between KMS providers — are RSA-OAEP key transport in production, not a diagram: the destination KMS publishes a temporary public key and a short-lived import token, the source system wraps the key material with that public key, uploads it, and the destination KMS is the only thing able to unwrap it, using the private half it never exposed. This is exactly the asymmetric transport pattern above, just with the KMS itself as the recipient.

Both wrapping approaches above still transmit an encrypted key. Diffie-Hellman and ECDH (covered in depth earlier in this catalog) solve a genuinely different problem: two systems derive the identical shared secret independently, without either one ever sending a key — encrypted or otherwise — across the wire. This is the pattern behind TLS's ephemeral key exchange and modern VPN tunnels, and it's the right tool whenever forward secrecy matters: if an attacker records the exchange and later compromises a long-term key, a wrapped key transported over RSA is retroactively exposed, but an ephemeral ECDH exchange leaves nothing recorded that reconstructs the session key.

The trade-off is payload size versus what you get for it. An X25519 ephemeral public key (the ECDH exchange itself) is a fixed 32 bytes, no matter what security level is needed at that curve — while an RSA-wrapped key transport payload scales with the RSA modulus, which has to be far larger than 32 bytes to reach equivalent security (the key-sizes module covers exactly why).

In practice these three tools compose rather than compete: a TLS session uses ECDHE to agree on a session key live, a backup system uses AES Key Wrap to move a key between two services that already trust each other, and a one-time cross-organization key handoff uses RSA-OAEP transport because there's no pre-shared secret and no live session to negotiate over.