We've reached the module's last lesson, and it's the one that ties every thread together. Throughout the course you've built up two families of tools with opposite virtues: symmetric cryptography (AES-GCM, ChaCha20) is blazingly fast and encrypts gigabytes, but demands a shared key we didn't know how to distribute; asymmetric cryptography (RSA, ECC) solves key distribution, but is slow and only handles tiny messages. Each one limps exactly where the other shines. The solution isn't to choose: it's to combine them. The pattern is called hybrid encryption or the digital envelope (envelope encryption), and it is, without exaggeration, how real encryption is actually done in the real world — from TLS to your cloud backups. In this lesson you'll build the whole thing: MediNube will send a full record export to Clínica Sol, and you'll see the two ways to "seal the envelope" (classic RSA-OAEP and the modern pattern with ephemeral X25519). We'll close the module with a decision map for every asymmetric primitive, and with the one piece we're still missing.

1. The dilemma, summed up in a table
2. The idea of the digital envelope
3. Digital envelope with RSA-OAEP (classic variant)
4. Digital envelope with ephemeral X25519 (modern variant, ECIES-like)
5. MediNube's versioned envelope format
6. Where this pattern lives in the real world
7. The module's decision map

Let's put what we know side by side, because the hybrid approach is born exactly from this tension:

Read the last row and you'll see the weaknesses fit together like puzzle pieces: what symmetric crypto can't do (distribute the key), asymmetric does effortlessly; what asymmetric crypto can't do (encrypt large data fast), symmetric does effortlessly. The conclusion we already anticipated in 04-01 — "RSA encrypts keys, not data" — turns here into an architecture.

Hybrid encryption uses each primitive for what it's good at:

1. Generate a random symmetric session key (a fresh AES-256 key, from the CSPRNG — golden rule 3), single-use.
2. Encrypt the data (which is large) with that key using AES-256-GCM: fast, no size limit.
3. Encrypt only the session key (32 bytes) with asymmetric cryptography, using the recipient's public key. There, asymmetric crypto's slowness and size limit don't get in the way: 32 bytes fit easily and only get encrypted once.
4. Send the envelope: the encrypted session key + the encrypted data, together.

The recipient does the reverse: with their private key they open the envelope and recover the session key; with it they decrypt the data.

The beauty of the pattern: you get confidentiality toward a recipient with a public key (no one else can open the envelope) with the speed of symmetric crypto (the data travels with AES). And since the session key is fresh every time, two identical exports produce completely different envelopes. All that's left to decide is how the envelope gets sealed — step 3 — and here there are two schools of thought.

If the recipient has an RSA key (like the public hospital in MediNube's integration), sealing the envelope is literally what you learned in 04-01: encrypt the session key's 32 bytes with RSA-OAEP.

Notice the key point: export can weigh megabytes and RSA doesn't care, because RSA only ever touches the 32-byte session key. The 318-byte limit from 04-01 stops being a problem. This is "RSA encrypts keys, not data" turned into code.

What if the recipient has an elliptic curve key (X25519), which — as you saw in 04-04 — doesn't encrypt directly? You combine the previous lesson's key exchange with the envelope: the sender generates an ephemeral X25519 pair, does ECDH against the recipient's static public key, derives the session key with HKDF, and attaches its ephemeral public key to the envelope. The recipient rebuilds the same secret with their private key and the received ephemeral public key. This pattern has its own name: ECIES (Elliptic Curve Integrated Encryption Scheme), and it inherits forward secrecy from 04-04 for free.

Differences from the RSA variant worth having clear:

In ECIES the session key isn't "encrypted": it's derived from an exchange, and the only thing that travels is the ephemeral public key — harmless, like any public key. That's why it gives forward secrecy almost for free, the same property that made ephemeral keys valuable in 04-04.

Example dictionaries are fine for learning, but to send the envelope over a channel or store it on disk, you need a concrete, versioned byte format, consistent with the v1 style we've carried since module 2 (version || ...). That way medinube/envelope.py can evolve without breaking old envelopes (crypto-agility, golden rule 8):

The first byte rules everything: whoever receives the envelope reads the version and knows exactly how to interpret it. The day MediNube adds a post-quantum scheme (06-05), it'll be 0x03; envelopes 0x01 and 0x02 will keep decrypting without touching anything. It's the same discipline as the AES-GCM v1 format (02-03) and the prescription's v1=<hex> signature (04-03): the version, always up front.

Compliance reminder. A record export is special-category health data. This code shows the cryptographic mechanics with fictional data; a real deployment requires security and data-protection (GDPR) review — just as we warned with the prescriptions.

Hybrid encryption isn't a trick from this course: it's the dominant pattern. Almost anything you encrypt daily is a digital envelope:

• TLS/HTTPS (module 5, lesson 05-02): every visit to https://portal.medinube.example negotiates a symmetric session key via asymmetric exchange (ECDHE) and encrypts traffic with AES-GCM or ChaCha20-Poly1305. It's exactly this lesson, with certificate-based authentication.
• PGP/GPG and age: file and email encryption. They generate a session key per message and protect it with the recipient's public key — textbook digital envelope. age is the modern, minimalist version, built on X25519 like your ECIES variant.
• KMS envelope encryption (a preview of 06-01): cloud key management services encrypt your data with a symmetric "data encryption key" (DEK) and, in turn, encrypt that DEK with a "key encryption key" (KEK) that never leaves the service. The vocabulary changes (DEK/KEK), the pattern is identical: encrypt the data with a symmetric key, protect that key with other cryptography. You'll see it again in module 6.
• End-to-end messaging (Signal, WhatsApp): they use much more sophisticated variants (the double-ratchet protocol) that go beyond the simple envelope, but their foundation is the same — X25519 to agree on keys, symmetric crypto for the messages. We only mention it here; its design is worth a course of its own.

Recognizing this pattern under all those names is one of the course's goals: they aren't ten different technologies, it's one idea applied ten times.

Close your eyes and review the whole module: which asymmetric primitive do you use for what you need? This table is the operational summary of the five lessons:

Pocket rule for choosing from memory: encrypt-toward-someone → hybrid (envelope); prove who issued it → signature (Ed25519); agree on a key → exchange (X25519). Three verbs, three tools. And all of them, underneath, leaning on the symmetric crypto and hashes from modules 2 and 3: nothing was thrown away, everything got combined.

• Chunking large data with RSA instead of using the hybrid pattern. The anti-pattern we already warned about in 04-01: encrypting a file in 318-byte blocks with RSA is agonizingly slow and cryptographically fragile. The digital envelope is the answer — one session key, one AES encryption.
• Reusing the session key across messages. It must be random and single-use per envelope. Reusing it reintroduces determinism (two identical exports would give identical ciphertexts) and risks AES-GCM's nonce rule.
• Forgetting the envelope's AAD. It binds the ciphertext to its context (destination, format) just like in 02-03. Without AAD, an attacker could redirect a valid envelope to a different recipient or format without decryption detecting it.
• Storing the envelope without a version. The version byte up front isn't decorative: it's what lets you add ECIES or post-quantum tomorrow without breaking today's envelopes. An unversioned format means an impossible migration.
• Believing the envelope authenticates the sender. Hybrid encryption gives confidentiality, not authenticity: anyone with your public key can fabricate you an envelope. If you need to know who sent it, you must sign as well as encrypt (04-03) — sign-then-encrypt, or combined schemes; the envelope alone doesn't give it to you.
• Using the RSA variant and expecting forward secrecy. RSA-OAEP doesn't have it: if the RSA private key is ever stolen, every recorded past envelope opens. If forward secrecy matters, use ephemeral X25519.
• And the usual one: trusting the recipient's public key at face value. The whole hybrid scheme assumes Clínica Sol's public key really is Clínica Sol's. We still don't know that for sure — it's the debt that closes the module, right below.

1. Round-trip versioned envelope. Using encrypt_hybrid_x25519 and the format from medinube/envelope.py: encrypt the export b"RECORD ana.perez\n" * 1000 with AAD b"destino=clinica-sol;formato=v1", pack it into a blob of bytes, print its first byte and its length, and unpack it, checking that you recover the original. Then change one byte of the blob's encrypted data and check which exception is raised when unpacking, and why (hint: AES-GCM, module 2).

2. The two envelopes, compared. Encrypt the same export with the RSA-OAEP variant and with the X25519 one. (a) Compare the size of the material that travels to "open the envelope" in each case. (b) Encrypt the same export twice with the X25519 variant and check that the ephemeral public keys (and hence the envelopes) differ. (c) Explain which security property that difference gives, and which of the two variants has it.

3. Confidentiality is not authenticity. MediNube receives a hybrid X25519 envelope that decrypts without error and contains an order: "register a new doctor." Reason it out (no code needed): (a) does successful decryption prove Clínica Sol sent the envelope? (b) If not, who could have fabricated it? (c) Which primitive from this module would need to be added for MediNube to trust the sender, and which pending problem would resurface by adding it?

It raises InvalidTag: AES-256-GCM's authentication tag (module 2) detects that a byte of the ciphertext changed and refuses to decrypt. The hybrid envelope inherits the integrity of its inner AEAD: it's not just confidential, it also detects tampering with the data.

(a) RSA sends 384 bytes over the wire (the encrypted session key); X25519, only 32 (the ephemeral public key). (b) Each X25519 encryption generates a fresh ephemeral pair, so the public keys — and the entire envelopes — differ even though the export is identical. (c) That renewal per envelope gives forward secrecy: the ephemeral X25519 variant has it, RSA-OAEP doesn't (whose single private key, if stolen, opens every past envelope).

3. (a) No. Hybrid encryption only proves that someone with MediNube's public key built the envelope — and that key is public. Decrypting correctly proves the data's confidentiality and integrity, not the sender's identity. (b) Anyone: MediNube's public key is published, so an attacker can build a perfectly valid envelope with whatever order they want. (c) You'd need to sign the content with the sender's private key (Ed25519, 04-03) and have MediNube verify it with the clinic's public key: that adds authenticity and non-repudiation. But doing so brings back the question of the module: how does MediNube know that verification public key really is Clínica Sol's? The answer — certificates and trusted authorities — is module 5.

You've closed the circle. Hybrid encryption combines the best of the course's two families: a random symmetric session key encrypts the data with AES-256-GCM (fast, no size limit), and asymmetric cryptography protects only that key (where its slowness and its limit don't matter). You built it in both its forms — classic RSA-OAEP and the modern ephemeral X25519 (ECIES) pattern, the latter with forward secrecy thrown in — in a versioned envelope format (0x01/0x02, the version always up front) consistent with the whole course, and you recognized the same pattern beating under TLS, PGP/age, KMS envelope encryption, and end-to-end messaging. This closes out Module 4, and with it your toolbox is complete: you have symmetric crypto (module 2) to encrypt fast, hashes and MACs (module 3) for integrity and authenticity with a shared secret, and asymmetric crypto (this module) to sign, agree on keys, and encrypt toward strangers with no prior secret. You can encrypt, sign, verify, and agree on keys over a public channel. And yet, lesson after lesson — 04-01, 04-03, 04-04, and just now in the last exercise — the same crack has kept reappearing: all the mathematics is flawless, but it rests on an unverified assumption, that the public key you have belongs to who you think it does. MalloryClinic is still out there, waiting for someone to trust a key without checking it. We're not missing new primitives: we're missing trust — a way to know, with verifiable backing, whose public key each one is. That's the one piece left, and it's exactly what Module 5: PKI, Certificates, and TLS builds, starting with X.509 certificates and certificate authorities in lesson 05-01. There, at last, we'll close the crack we've carried through the whole module. See you in module 5.