Why is a 4 MB file never encrypted directly under an RSA public key, and what does the standard hybrid (envelope) construction do instead? Derive the size limit rather than quoting a number.

## Deriving the ceiling The RSA operation is arithmetic on integers modulo n: the message is interpreted as a number and must be smaller than the modulus, or the result is ambiguous. The modulus size is the key size, so a 2048-bit key gives a 256-byte block and a 3072-bit key gives 384 bytes. Secure padding is not optional (an unpadded operation is deterministic and malleable), and randomized padding costs a fixed overhead of about two hash outputs plus a couple of bytes - roughly 66 bytes with a 256-bit hash - leaving under 200 usable bytes on a 2048-bit key. That is the derivation: usable payload equals modulus bytes minus padding overhead. ## Why you cannot just loop Symmetric ciphers have standardized modes that turn a fixed-width block cipher into something that safely handles arbitrary length. Public-key primitives have no such mode. Encrypting a file chunk by chunk under the same public key is an ad-hoc codebook construction: identical chunks yield identical ciphertext, chunks can be deleted, duplicated or reordered undetectably, and you have invented a scheme nobody has analysed. The cost argument is just as decisive - the modular exponentiation is several orders of magnitude slower per byte than a symmetric cipher, so the file would take minutes rather than milliseconds. ## Families diverge on what the wrap even is With RSA you literally encrypt the data key under the recipient's public key. With elliptic-curve Diffie-Hellman there is no encryption step: you generate an ephemeral key pair, agree a shared secret with the recipient's static public key, run it through a key-derivation function and use the result to wrap the data key; the ephemeral public value travels with the ciphertext. With a post-quantum key-encapsulation mechanism the primitive hands you a random shared secret plus an encapsulation blob. All three end at the same place - a symmetric key protecting the bulk - by different routes, which is why the envelope format, not the primitive, is what an implementation actually standardises. ## What the envelope buys beyond size - **Multiple recipients.** One bulk ciphertext, the data key wrapped once per recipient. Adding a recipient is a rewrap, not a re-encryption. - **Cheap rotation of the asymmetric key.** Rotating the key pair means rewrapping small data keys; the terabytes are untouched. This only works if every ciphertext records which key wrapped it - a key identifier in the envelope is what makes rotation and revocation possible at all. - **A clean split of responsibility.** The private key can live in hardware that only ever performs the small unwrap operation and never sees the payload. ## Two failure modes to name The data key must come from a cryptographically secure random source and must be fresh per object; reusing one across objects turns a single compromise into a total one. And the bulk cipher must be authenticated - the wrap protects the key, not the payload, so an attacker who cannot decrypt can still tamper with unauthenticated bulk ciphertext.