Transporting a Key Versus Agreeing on One

Two parties need a symmetric key. One of them has a public key belonging to the other and no other shared secret. There are two ways forward: encrypt a freshly generated key to the other party’s public key, or run a computation that both parties contribute to and that yields the same key on both sides. Both produce a symmetric secret that neither an eavesdropper nor an active attacker can determine. They differ in what the sender must do, what happens to past traffic when a private key leaks, and how the key is bound to the identities involved.

Encrypting a key to a public key

Key transport is the direct approach. The sender generates a symmetric key, encrypts it under the recipient’s public key, and sends the ciphertext. The recipient decrypts with its private key and uses the result.

The construction has to handle more than the textbook case. Encrypting a key under RSA without a proper padding scheme is deterministic, so the same key produces the same ciphertext, and a chosen-ciphertext attacker can recover the plaintext. The standard answer is a randomized, integrity-checked padding such as OAEP, and NIST SP 800-56B covers the overall scheme, including the requirements on the key pair, the padding, and the encoding of the key material into the plaintext. The size of the plaintext is bounded by the modulus: a 2048-bit modulus and a hash function with a 256-bit output leave far less than 256 bytes of room once the padding is accounted for, which is ample for a symmetric key and insufficient for anything larger.

The structural weakness is that only one party contributes to the key. If the recipient’s private key is later compromised, every transported key in recorded traffic can be decrypted, and every session those keys protected is retroactively exposed. Transport has no forward secrecy by construction: the key existed in encrypted form on the wire, and the decryption key is the long-term private key.

Key transport is not obsolete. It is the right shape when one side has a public key and the other has no way to publish one, when the exchange must be one message rather than back-and-forth, or when the sender is a constrained device that cannot perform an expensive public-key operation more than once. It is also the shape of a backup or escrow mechanism, where a key is deliberately encrypted to a long-term recovery key.

Agreement by contributed shares

Key agreement computes a shared value from both parties’ private inputs. In Diffie-Hellman over a finite field, a group generator g, and a large prime p, each party picks a private exponent and publishes g raised to that exponent modulo p. Each then raises the other’s public value to its own private exponent, and both obtain g raised to the product of the two exponents. An eavesdropper sees the two public values and must solve the discrete logarithm problem to derive the shared value.

Elliptic curve variants replace the exponentiation with scalar multiplication, where the security per bit of key is higher and the group order is prime, which avoids the small-subgroup issues of finite-field groups. NIST SP 800-56A covers both, along with the validation each party must perform on the received public value: the point must be on the curve, in the correct subgroup, and not the identity. Skipping that validation is the standard source of small-subgroup attacks, where an attacker sends a value of low order and learns the victim’s private exponent one residue at a time.

Raw agreement output is not a key. It is a group element with structure, and using its encoding directly as an AES key is a mistake: the bits are not uniformly distributed in the way a key must be. The standard is to run the shared value through a key derivation function, with the transcript — both public values, the identities — included as context. That step does two things: it produces uniformly distributed key material, and it binds the key to the particular exchange, so a value from one session cannot be replayed into another.

The binding is what handles the authentication gap. Plain Diffie-Hellman is unauthenticated: an active attacker can sit between the parties, agree one key with each, and relay. Authentication comes from signing the transcript with long-term keys, or from a pre-shared secret mixed into the derivation, or from a password-authenticated variant. The mix must cover the identities and the public values, or the attacker can substitute its own values and still complete the protocol.

Forward secrecy is a property of the contribution

The distinction that matters operationally is what happens later. In key agreement where both parties generate ephemeral private values and discard them, a subsequent compromise of the long-term signing key does not reveal the session keys: the ephemeral secrets are gone, and the shared value cannot be recomputed from the transcript. In key transport, or in agreement with a static private key, the long-term key alone suffices to recover the session key from recorded traffic.

TLS 1.3, specified in RFC 8446, makes this concrete. Its key exchange is ephemeral Diffie-Hellman over a named group, and the handshake is designed so that the long-term key authenticates the exchange rather than contributing to the secret. The protocol also removed the static RSA key transport mode that earlier versions supported, on the grounds that its lack of forward secrecy made recorded traffic decryptable after a key compromise. Sessions resumption in TLS 1.3 uses a pre-shared key derived from an earlier session, mixed with a fresh ephemeral exchange in the same way, so the resumption path also retains forward secrecy.

The cost is a round trip and a public-key operation per session, and the requirement that both sides can perform them. Where one side cannot, transport returns, with the exposure it implies.

Hybrid construction and the migration problem

A protocol that must survive the eventual availability of a large quantum computer cannot rely on either RSA or elliptic curve Diffie-Hellman alone, since both fall to Shor’s algorithm. The practical response is to run two exchanges and combine the results: a classical agreement and a post-quantum one, with the shared secrets concatenated and passed through the same derivation. The combination is secure if either component is, which is the property that makes it usable during a migration when the post-quantum component is newer and less studied.

The combination must be done in the derivation, not by choosing one of the two at random. Truncating to the shorter output, or XORing two secrets of different lengths, loses the guarantee: an attacker who breaks one component may be able to force a predictable value in that component and then control the combined output. Concatenating both and running a KDF over the result, with the transcript as context, keeps the security dependent on the stronger of the two.

Conventions matter here. A hybrid exchange between two implementations that concatenate the two secrets in different orders derives different keys and fails, and a hybrid where one side sends a classical share and the other a post-quantum share is not a hybrid at all. The details of the composition belong to the protocol specification, not to the application, which is the general reason to use a defined handshake rather than to assemble one.

Choosing between them

The decision reduces to a few questions. Does the sender have a way to obtain the recipient’s public key and to be sure of its authenticity? Is a round trip affordable? Must recorded traffic remain secret after a long-term key compromise? Is either side unable to perform an ephemeral public-key operation?

Transport answers yes to the first and no to the second and third. Agreement answers the reverse. Systems frequently need both: an initial authenticated agreement to establish a session, and transport of a key to a party that joins later or that cannot participate in the exchange.

The output of either is a symmetric key that then enters a hierarchy: it may wrap a data key, as described in envelope encryption, or it may protect a session directly with a bounded message count that requires rotation before the counter space is exhausted. In both cases the derivation step, not the exchange, decides what the key is bound to, which is why the transcript and the identities have to be part of it. The handling of the resulting key inside a process — its lifetime, its protection, its destruction — is where the exchange’s guarantees either survive or are lost, and the constraints on shuffling keys between parties without a single holder are covered in threshold secret sharing.