The course's final lesson, and it opens with a confession owed since module 4: when we designed MediNube's hybrid envelope, we reserved the byte 0x03 "for the future." That future has a name: post-quantum cryptography (PQC). In this lesson you'll understand exactly what a quantum computer threatens (and what it doesn't — there's a lot of noise out there), why "harvest now, decrypt later" turns this into a problem for today when it comes to medical records that must stay confidential for decades, who NIST's chosen algorithms are (ML-KEM, ML-DSA, SLH-DSA), why the world is migrating in hybrid mode, and what MediNube needs to do right now — spoiler: most of the work got done back in 06-01 without anyone realizing it. And at the end, we'll close the course by looking back at the road we've traveled.

1. What a quantum computer threatens (and what it doesn't)
2. Harvest now, decrypt later: why this is a today problem
3. The NIST process and the winners: ML-KEM, ML-DSA, SLH-DSA
4. What a KEM is (and how it differs from Diffie-Hellman)
5. The price in bytes: sizes compared
6. The hybrid strategy: X25519 + ML-KEM
7. The 0x03 byte: MediNube's post-quantum envelope
8. What MediNube must do today
9. A rough migration timeline

Two quantum algorithms matter here, and they do very different things:

• Shor (1994): solves integer factorization and the discrete logarithm problem (elliptic-curve version included) efficiently. In other words: a sufficiently large quantum computer breaks RSA, Diffie-Hellman, and all of elliptic-curve cryptography — Ed25519, X25519, P-256, P-384. It doesn't weaken them: it breaks them outright. All of module 4's asymmetric cryptography and module 5's certificate signatures are on the list.
• Grover (1996): speeds up brute-force search quadratically: searching among 2¹²⁸ possibilities costs "only" ~2⁶⁴ quantum operations. Against symmetric cryptography and hashes there's no structural shortcut, just this speedup: the defense is doubling the size. AES-256 keeps ~128 bits of post-quantum security; SHA-256 remains solid for what we use it for. (And in practice, Grover parallelizes so poorly that many cryptographers consider it even less threatening than its theoretical bound suggests.)

Let's apply this to the arsenal MediNube has built over the course:

The pattern is sharp: symmetric crypto and hashes hold; asymmetric crypto falls entirely. That's why PQC doesn't touch AES or SHA-2: it replaces key exchange and signatures.

Honesty about "when": today, no quantum computer exists that can run Shor against real-world keys (you'd need millions of physical, error-corrected qubits; today's machines have thousands, and they're noisy). Serious estimates put a real possibility 10-20 years out, with huge uncertainty. So why not just wait?

Because the attacker doesn't need the quantum computer today — all they need is to record today and decrypt tomorrow. That's the harvest now, decrypt later strategy: capture encrypted TLS traffic (or steal asymmetric blobs at rest) and store them patiently until Shor becomes runnable. Everything that today travels protected only by X25519 or RSA will be retroactively exposed.

The design question is: how long does your data need to stay confidential? And here MediNube is the textbook case, almost literally:

• A medical record must stay confidential for decades — the patient's lifetime and beyond. Ana Pérez's record, intercepted in transit today and decrypted in 2040, is a real 2040 breach built from data captured in 2026.
• The GDPR doesn't expire with technology: health data is a special category (Art. 9), and "appropriate technical measures" (Art. 32) is interpreted against the state of the art at the time of processing and of the foreseeable risk. The quantum threat is already a documented foreseeable risk, per ENISA, NIST, and European agencies.
• By contrast, a JWT with a 15-minute exp or a webhook with a 300-second window interests nobody in 2040: the secret's useful lifetime sets the urgency.

This asymmetry produces the whole lesson's practical rule: channels that carry long-lived data (confidentiality) migrate first; signatures (authenticity) come after. A signature only needs to be secure at the moment it's verified; a secret needs to be secure for its entire lifetime.

Where do post-quantum algorithms come from? A public competition: NIST opened a worldwide contest in 2016 — 82 candidates, years of open analysis, elimination rounds where cryptographers from around the planet tried to break their competitors' designs (and several fell spectacularly: SIKE, a finalist, was broken in 2022 with a laptop). It's Kerckhoffs institutionalized, once again: trust doesn't come from secrecy but from years of public scrutiny that failed to break the design. Exactly like AES in 1997-2001.

The published standards (2024), with their contest name in parentheses:

• ML-KEM (Kyber) — FIPS 203: key encapsulation (KEM), the replacement for key exchange. Based on lattices (the Module-LWE problem). It's the workhorse: fast, reasonable sizes.
• ML-DSA (Dilithium) — FIPS 204: digital signatures, also lattice-based. The general-purpose replacement for RSA-PSS/Ed25519 in signing.
• SLH-DSA (SPHINCS+) — FIPS 205: signatures based only on hashes. Maximally conservative: its security rests on SHA-2/SHAKE, the part of the arsenal we already know survives. The price: huge, slow signatures. It's the "plan B" in case lattices hold surprises, and the choice for very-long-lived signatures (firmware, roots of trust).

ML-KEM isn't "a post-quantum Diffie-Hellman": it's a KEM (Key Encapsulation Mechanism), and the shape of the difference matters for integrating it. Recall 04-04's ECDH: both parties contribute their own keypair, both run the same operation, and they arrive at the same secret — it's symmetric in its choreography. A KEM is asymmetric in its choreography too, and you actually already know its shape, because it's the shape of our 04-05 hybrid envelope:

1. keygen() → the recipient (MediNube) publishes its public encapsulation key.
2. encaps(public_key) → the sender simultaneously generates a shared secret k and a ciphertext c (the "capsule") and sends c. It doesn't choose k: the algorithm produces it.
3. decaps(private_key, c) → the recipient recovers the same k.

After that, k runs through HKDF and feeds AES-GCM: the symmetric part doesn't change at all. Notice: DH allows patterns a KEM doesn't give you directly (both parties contribute entropy symmetrically), which is why TLS had to adapt its handshake to treat the exchange as encapsulation. But for the "encrypt toward a public key" pattern — our envelope — a KEM fits naturally: where envelope 0x02 did "ephemeral X25519 + HKDF," the post-quantum envelope will do "encaps + HKDF."

PQC isn't free: keys and signatures grow. This table is the one that explains why migration takes engineering, not just a pip install (figures for the usual security levels — ML-KEM-768, ML-DSA-65, SLH-DSA-SHA2-128s):

Practical takeaways: an ML-KEM in the TLS handshake adds ~2 KB — barely noticeable, which is why it's already deployed. A certificate chain where every signature weighs 3-8 KB instead of 64-384 B is a different story: certificates of tens of KB, which is why migrating the PKI (module 5) will be the slowest part of the worldwide process. A JWT signed with ML-DSA goes from ~300 bytes to ~5 KB — it still fits in an HTTP header, but it stops being "lightweight."

Lattice-based algorithms have a good decade of analysis behind them; X25519 has a quarter century. What if ML-KEM hides a classical weakness nobody's found yet (as happened to SIKE)? Current consensus answers by not choosing: go hybrid. Both exchanges run, and keys get derived from the concatenation of both secrets:

The property that matters is this: if either one holds, the session holds. A classical cryptanalytic break of ML-KEM doesn't expose you (X25519 holds the line); a future quantum computer doesn't either (ML-KEM holds the line). You only fall if both fall.

And this isn't lab theory: the X25519MLKEM768 group is already negotiated by default between major browsers and large CDNs since 2024-2025. You can check it yourself: open your browser's developer tools on a major website and look at the connection security details. Part of the TLS 1.3 we studied in 05-02 is already post-quantum in its key exchange — the upgrade comes to you through the evolution of OpenSSL/BoringSSL and your web server, not through your application code. Certificate signatures, on the other hand, are still classical: confidentiality is already protected (against harvest-now), authenticity will migrate later — consistent with the rule from the previous section.

Time to settle the course's last outstanding reservation. The envelope in medinube/envelope.py (04-05) versions its first byte: 0x01 = RSA-OAEP, 0x02 = X25519-ECIES, 0x03 = reserved. The conceptual design for 0x03 is a classical + PQ hybrid envelope:

Familiar pieces, one novelty: the recipient now publishes two public keys (X25519 + ML-KEM); the sender does the usual ephemeral ECDH and an encapsulation, and HKDF mixes both secrets together. The final AES-GCM step is identical to 0x02's. The header grows by ~1.1 KB per envelope: irrelevant next to a medical record.

Honesty about the ecosystem's current state: as of today, pyca/cryptography — our go-to library — is incorporating ML-KEM/ML-DSA, but support is still settling, and the alternatives (liboqs-python, various wrappers) are evolving fast. That's why we present 0x03 as a sketched design, not production code: MediNube leaves the format defined and the decision documented, and will implement it once its reference library offers it in a stable form. This is a lesson in itself: in cryptography, arriving first with an immature implementation is worse than arriving second with a solid one (rule 1, in its "don't be the one who integrates what isn't ready yet either" version).

No panic, and no heroics. The realistic list — and you'll notice most of it is already done:

1. Cryptographic inventory: knowing exactly which algorithms, keys, and formats are in use, and where. It's literally 06-01's table plus this lesson's "survives?" column. No inventory, no migration plan — and the official guides (NIST, ENISA) all start right here.
2. Crypto-agility: golden rule 8, cashing in for the second time this module. Migrating to PQC will mean swapping 0x02 for 0x03, v2 for v3, one kid for another — because every one of our formats carries a version. A system with no versioning faces the PQC migration by rewriting itself; MediNube faces it with a byte.
3. Watch TLS and libraries: keeping OpenSSL/nginx/requests up to date already gives us the hybrid in transit, which is the urgent front (harvest-now). Add a check to 05-03's monitor for which groups our endpoints negotiate.
4. Symmetric crypto is already sized right: AES-256 and SHA-256 since modules 2-3. Nothing to touch here — the "256 bits, standard" decision from rule 5 was, without anyone knowing it, a post-quantum decision too.
5. Don't panic, and don't buy hype. Be wary of anyone selling "quantum-safe security" with commercial urgency. The calendar is set by standards and serious libraries, not by marketing.

What migrates first? You already have the criterion: the secret's useful lifetime, and the cost of the change.

Notice the last row: the short-lived-by-design architecture from 05-03 and 06-03 turns out to also be a post-quantum defense. Good principles pay for themselves more than once.

• Mistake: "the quantum computer will break all encryption." No: it breaks today's asymmetric crypto (Shor). AES-256, SHA-256, HMAC, and Argon2 survive with margin to spare. Precision above all — including when you explain it to leadership.
• Mistake: waiting for the threat to become tangible. For data with decades of required confidentiality, harvest-now means today's classical encryption is tomorrow's breach. Urgency depends on the data's useful lifetime, not the date of the first useful qubit.
• Mistake: migrating to pure PQC "to get ahead." The consensus is hybrid precisely because the new algorithms have less track record; SIKE fell as a finalist. Being post-quantum doesn't make an algorithm immune to classical cryptanalysis.
• Mistake: implementing Kyber by hand from a paper (or a gist). Rule 1 doesn't expire in the future: wait for pyca/cryptography, or use maintained bindings to audited implementations.
• Tip: measure your crypto-agility with one question: "how many places do I have to touch to switch signing algorithms?" If the answer is "one: the version/kid registry," you're ready for this decade.

1. Post-quantum triage: classify these five MediNube elements by PQC migration urgency (now / short / medium / last) and justify with the secret-lifetime criterion: (a) api.medinube.example's TLS; (b) 0x02-envelope-encrypted backups kept for 25 years; (c) the portal's JWTs (exp 15 min); (d) Ed25519 prescription signatures valid for 30 days; (e) HMAC-SHA256 webhooks.
2. The 0x03 envelope, on paper: without writing production code, specify the hybrid envelope's decrypt: which fields get extracted from the blob (with offsets, knowing the X25519 public key is 32 B, the ML-KEM-768 capsule is 1088 B, and the nonce is 12 B), which two operations produce k1 and k2, and why the HKDF info must differ from 0x02's.
3. Explain it to leadership: write (5-7 lines) the executive summary you'd send to MediNube's leadership justifying the post-quantum plan: the threat, why it affects health data even though the quantum computer doesn't exist yet, what's already been done, and what comes next. No jargon: no "lattices," no "Shor."

1. (a) Now: a channel carrying medical records → harvest-now; also cheap (updating the TLS stack to hybrid). (b) Now/short: the most serious case — 25 years of useful life and classical asymmetric protection; as soon as 0x03 is implementable, re-encrypt the envelopes (the inner symmetric key is already AES-256: only the envelope layer gets redone). (c) Last: 15 minutes of life; no 2040 adversary gains anything. (d) Medium: 30 days is short, but archived prescriptions might need re-verification years later in a dispute — if so, they move up to medium term with a timestamp; if they're only ever checked at dispensing time, urgency drops. The right question is "when is it last verified?" (e) Last, or never: HMAC is symmetric, Grover barely dents it; with a 256-bit key it's already ready as-is.
2. Structure: blob[0] == 0x03 (otherwise, delegate to the 0x01/0x02 decryptors — crypto-agility); ephemeral_pub = blob[1:33]; capsule = blob[33:1121]; nonce = blob[1121:1133]; ct = blob[1133:]. Operations: k1 = X25519(recipient_x25519_private, ephemeral_pub); k2 = decaps(recipient_mlkem_private, capsule); key = HKDF-SHA256(k1 || k2, info=b"medinube:sobre:v3"); AESGCM(key).decrypt(nonce, ct, aad). The different info (v3 ≠ v2) applies 02-04's domain separation: even if, by some accident, the secrets matched those of another context, the derived keys would still differ; no key is ever shared between formats.
3. Example: "Quantum computers, expected within the next one to two decades, will be able to break the key-exchange and signature technology that protects the Internet today. This isn't a future problem: an attacker can record our encrypted traffic today and decrypt it later, and our medical records must stay confidential for decades, as the GDPR requires for health data. We've already done the essential work: our storage encryption uses algorithms that resist this threat, and all of our cryptography is versioned, so switching algorithms is a controlled update, not a rewrite. Next steps: turn on quantum-resistant hybrid mode on our connections (already standard in browsers) and update our long-lived file format once the libraries mature, expected within the normal maintenance cycle."

And with the 0x03 byte sketched out, no promise is left open. It's a good moment to look back, because MediNube's journey has been your journey too.

We started in module 1 with a portal that confused encoding with encrypting: an editable Base64 token, API keys in a dictionary in the code, recovery tokens spat out by random. There you learned the 9 golden rules and how to tell the goal from the tool. In module 2, Ana Pérez's medical records started traveling in AES-256-GCM with AAD and a version byte that felt like bureaucracy at the time. Module 3 brought integrity: webhooks with HMAC and an anti-replay window, Argon2id passwords, tokens stored as hashes. Module 4 opened the asymmetric world: Dr. Ferrer signing prescriptions with Ed25519, X25519 giving us forward secrecy, and the hybrid envelope with its version bytes. Module 5 turned public keys into identities: certificates, the mini-PKI, TLS 1.3, mTLS for clinics, and the lesson of the incident — the key that fell to a git push. And this module 6 carried it all into real-world development: secrets into the manager with envelope encryption, the layered encryption map with verify-full reaching all the way to the database, the old Base64 token turned into an EdDSA JWT with a kid, an auditor's eye cast over every _BAD, and today, the plan for the one threat that doesn't exist yet.

Notice what keeps repeating: almost nothing that made MediNube better was a stronger primitive. It was using well what already existed: versioning formats, separating keys by purpose, expiring fast, always verifying, never inventing, comparing in constant time, assuming the enemy reads your repo. The 9 golden rules from day one are the course's legacy: come back to them every time you review code — today you've seen that even post-quantum migration is, at bottom, rule 8 applied well.

To keep growing from here: practice deliberately — the cryptopals challenges will have you break what you learned to build here, which is the other half of understanding; read post-mortems of real cryptographic incidents (the CAs', JWT's, reused nonces': each one is a lesson from this gallery with names and dates attached); follow the libraries you use (the changelogs of pyca/cryptography and OpenSSL are a continuing course of their own); and keep the inventory and the checklist alive in your own projects, because cryptography breaks down over mundane details when nobody's looking.

That's all there is. MediNube is in good hands: yours. Thank you for making it this far — and may your nonces always be unique.