Symmetric ciphers such as AES encrypt bulk data orders of magnitude faster per byte than public-key operations such as an RSA private-key operation or an elliptic-curve key-agreement step. Derive where that gap comes from in terms of what each primitive actually computes, and then compare the three topologies by which a shared symmetric key can get into place — an interactive key-agreement handshake, store-and-forward per-message key wrapping, and a key-management service that returns a data key both in usable and in protected form — saying what each one assumes about liveness and trust.

## Two classes of computation A symmetric cipher is assembled from operations a CPU already performs in a single instruction: XOR, addition, rotation, table lookup, or a dedicated round instruction. A block cipher applies a small fixed number of such rounds to a fixed-width block (128 bits for AES), so encrypting N bytes costs roughly N/16 times a small constant. The work is linear in the data and the per-unit constant is tiny; with hardware support for the round function and for the carry-less multiplication used by an authentication tag, a single core moves several gigabytes per second — usually faster than the disk or network it is feeding. A public-key operation computes in a large algebraic structure. An RSA-style operation is exponentiation modulo an integer of two to four thousand bits. An elliptic-curve agreement or signature step is scalar multiplication of a point: hundreds of doublings and additions, each itself several multi-word field multiplications. One such operation is thousands of arithmetic steps on numbers that do not fit in a register. As orders of magnitude: a symmetric block is nanoseconds, a curve scalar multiplication is tens of microseconds, an RSA-2048 private-key operation is around a millisecond. ## The gap belongs to the primitive, not the implementation Both families are heavily optimised, so the gap is not sloppy code on one side. An asymmetric primitive must carry enough mathematical structure for the public and private roles to differ — a trapdoor — and that structure is precisely what forces the arithmetic into a large group. You cannot engineer it away; you can pick a cheaper group (curves instead of big integers) and shift the constant. The consequence that matters architecturally is that asymmetric cost is **per operation** while symmetric cost is **per byte**, so the design question becomes how many public-key operations the system performs and when. That the payload therefore travels under a symmetric key which a public-key operation protects — the envelope construction, and the ceiling on how much a public-key encryption can carry — is derived under asymmetric/hybrid encryption; take it as established here. What remains is how the symmetric key gets into place, and there are only three topologies. ## Topology 1: interactive key agreement Both endpoints are live at the same time and exchange fresh key-agreement shares; each derives the same secret without it ever crossing the wire, and a key-derivation step turns it into working keys. Assumptions: a live peer, at least one round trip (zero-round-trip modes exist with their own replay caveats), and authentication of at least one side — otherwise you have successfully agreed a key with whoever sits in the middle. What it buys, when the shares are ephemeral and discarded afterwards, is forward secrecy: recovering a long-term private key later does not decrypt recorded traffic. If instead one side encrypts a key to the other's long-term static public key, there is no forward secrecy. The property comes from ephemerality, not from the fact that a handshake occurred. ## Topology 2: store-and-forward per-message wrapping There is no live peer. The sender generates a fresh symmetric key per message, protects the payload with it, and protects that key once for each intended recipient. Assumptions: recipient public keys are known in advance and their authenticity comes from outside the message (a directory, a certificate, a pinned fingerprint) — if that binding is weak, everything above it is; the recipient may be offline arbitrarily long, so the ciphertext must be self-describing about which key and which algorithm; and there is no forward secrecy, because whoever ever obtains the recipient's long-term private key can open the retained ciphertext years later. Fan-out is over recipients rather than over bytes. ## Topology 3: custodian-issued data keys A key-management service holds a master key that never leaves its boundary and issues freshly generated data keys, returning each in usable form and in a form only the service can reverse; the caller uses the usable copy, discards it from memory, and stores the other alongside the ciphertext. Assumptions: the custodian is online and available at both encrypt and decrypt time, so its outage becomes a data outage unless you cache; it is trusted, since it necessarily sees the plaintext data key it issued and is a single high-value compromise point; and each issuance is a network round trip, so you amortise one data key across a batch rather than calling per record. What you buy is that no long-term key material lives in your process, plus centralised authorisation, audit and revocation. ## Choosing, and what cost forces downstream The constraints pick the topology, not taste. Simultaneous liveness and a need to survive later key compromise push you to agreement. An offline or future recipient forces wrapping and rules forward secrecy out. A requirement that the process never hold long-term key material, plus tolerance for an operational dependency, points at a custodian. Real systems combine them — a custodian issues data keys for objects at rest while the transport between services uses agreement. The same cost asymmetry shapes three further decisions. Denial-of-service pressure sits on connection establishment rather than data transfer, because asymmetric work scales with connections and the side performing the private-key operation pays it; session resumption, connection reuse and handshake offload are capacity levers, not micro-optimisations. A single symmetric key has data limits — a birthday bound tied to the block size, and for authenticated modes a bound on distinct nonces — so very large objects are split into chunks, each protected separately with its position and the total count bound in, so chunks cannot be reordered, dropped or spliced. And long-lived streams rekey by deriving a fresh key from the already-established secret, which is symmetric-cheap, rather than repeating a handshake, which is not.