Última lliçó del curs, i comença amb una confessió pendent des del mòdul 4: quan vam dissenyar el sobre híbrid de MediNube vam reservar el byte 0x03 "per al futur". Aquell futur té nom: criptografia post-quàntica (PQC). En aquesta lliçó entendràs què amenaça exactament un ordinador quàntic (i què no — hi ha molt soroll), per què "harvest now, decrypt later" converteix això en un problema d'avui per a historials mèdics que han de ser confidencials durant dècades, qui són els algorismes triats pel NIST (ML-KEM, ML-DSA, SLH-DSA), per què el món està migrant en mode híbrid, i què ha de fer MediNube ja — spoiler: la major part de la feina la vam fer a 06-01 sense saber-ho. I al final, tancarem el curs mirant el camí recorregut.

1. Què amenaça un ordinador quàntic (i què no)
2. Harvest now, decrypt later: per què això va d'avui
3. El procés NIST i els elegits: ML-KEM, ML-DSA, SLH-DSA
4. Què és un KEM (i en què es diferencia de Diffie-Hellman)
5. El preu en bytes: mides comparades
6. L'estratègia híbrida: X25519 + ML-KEM
7. El byte 0x03: el sobre post-quàntic de MediNube
8. Què ha de fer MediNube avui
9. Cronologia orientativa de migració

Dos algorismes quàntics importen aquí, i fan coses molt diferents:

• Shor (1994): resol en temps eficient la factorització d'enters i el logaritme discret (també en corbes el·líptiques). És a dir: un ordinador quàntic prou gran trenca RSA, Diffie-Hellman i tota la criptografia de corba el·líptica — Ed25519, X25519, P-256, P-384. No les debilita: les trenca del tot. Tota l'asimètrica del mòdul 4 i les signatures dels certificats del mòdul 5 són a la llista.
• Grover (1996): accelera la cerca per força bruta de forma quadràtica: cercar entre 2¹²⁸ possibilitats costa "només" ~2⁶⁴ operacions quàntiques. Contra la criptografia simètrica i els hashes no hi ha drecera estructural, només aquesta acceleració: la defensa és doblar la mida. AES-256 manté ~128 bits de seguretat post-quàntica; SHA-256 continua sent sòlid per al que el fem servir. (I a la pràctica, Grover paral·lelitza tan malament que molts criptògrafs el consideren encara menys amenaçador que la seva cota teòrica.)

Apliquem-ho a l'arsenal que MediNube ha construït durant el curs:

El patró és nítid: la simètrica i els hashes aguanten; l'asimètrica cau sencera. Per això la PQC no toca AES ni SHA-2: substitueix l'intercanvi de claus i les signatures.

Honestedat sobre el "quan": avui no existeix cap ordinador quàntic capaç d'executar Shor sobre claus reals (calen milions de qubits físics amb correcció d'errors; els actuals en tenen milers, sorollosos). Les estimacions serioses parlen d'una possibilitat real en 10-20 anys, amb enorme incertesa. Aleshores, per què no esperar?

Perquè l'atacant no necessita l'ordinador quàntic avui: li n'hi ha prou amb gravar avui i desxifrar demà. És l'estratègia harvest now, decrypt later: capturar trànsit TLS xifrat (o robar blobs asimètrics en repòs) i emmagatzemar-lo pacientment fins que Shor sigui executable. Tot el que avui viatja protegit només per X25519 o RSA quedarà retroactivament exposat.

La pregunta de disseny és: quant de temps han de romandre confidencials les teves dades? I aquí MediNube és el cas perfecte, gairebé de llibre:

• Un historial mèdic ha de ser confidencial durant dècades — la vida del pacient i més enllà. L'historial d'Ana Pérez interceptat avui en trànsit i desxifrat el 2040 és una bretxa real de 2040 amb dades capturades el 2026.
• El RGPD no caduca amb la tecnologia: les dades de salut són categoria especial (art. 9), i les "mesures tècniques adequades" (art. 32) s'interpreten contra l'estat de l'art del moment del tractament i del risc previsible. L'amenaça quàntica ja és risc previsible documentat per ENISA, NIST i les agències europees.
• En canvi, un JWT amb exp de 15 minuts o un webhook amb finestra de 300 s no interessen a ningú el 2040: la vida útil del secret defineix la urgència.

Aquesta asimetria produeix la regla pràctica de tota la lliçó: primer els canals que transporten dades longeves (confidencialitat), després les signatures (autenticitat). Una signatura només necessita ser segura en el moment de verificar-se; un secret necessita ser-ho durant tota la seva vida.

D'on surten els algorismes post-quàntics? D'un concurs públic: el NIST va obrir el 2016 una competició mundial — 82 candidats, anys d'anàlisi obert, rondes eliminatòries on criptògrafs de tot el planeta van intentar trencar els dissenys dels seus competidors (i diversos van caure de forma espectacular: SIKE, finalista, va ser trencat el 2022 amb un portàtil). És Kerckhoffs institucionalitzat, un altre cop: la confiança no ve de l'ocultació sinó d'anys d'escrutini públic fallit. Exactament com l'AES el 1997-2001.

Els estàndards publicats (2024), amb el seu nom de concurs entre parèntesis:

• ML-KEM (Kyber) — FIPS 203: encapsulació de claus (KEM), el substitut de l'intercanvi de claus. Basat en reticles (lattices, problema Module-LWE). És el cavall de batalla: ràpid, mides raonables.
• ML-DSA (Dilithium) — FIPS 204: signatures digitals, també sobre reticles. El substitut general de RSA-PSS/Ed25519 per signar.
• SLH-DSA (SPHINCS+) — FIPS 205: signatures basades només en hashes. Conservador al màxim: la seva seguretat es recolza en SHA-2/SHAKE, la part de l'arsenal que ja sabem que sobreviu. El preu: signatures enormes i lentes. És el "pla B" per si els reticles amaguen sorpreses, i l'opció per a signatures de vida molt llarga (firmware, arrels de confiança).

ML-KEM no és "un Diffie-Hellman post-quàntic": és un KEM (Key Encapsulation Mechanism), i la diferència de forma importa per integrar-lo. Recorda l'ECDH de 04-04: les dues parts aporten el seu parell de claus, totes dues executen la mateixa operació i arriben al mateix secret — és simètric en la seva coreografia. Un KEM és asimètric també en la coreografia, i en realitat ja el coneixes, perquè és la forma del nostre sobre híbrid de 04-05:

1. keygen() → el receptor (MediNube) publica la seva clau pública d'encapsulació.
2. encaps(publica) → l'emissor genera alhora un secret compartit k i un ciphertext c (la "càpsula") i envia c. No tria k: l'algorisme el produeix.
3. decaps(privada, c) → el receptor recupera el mateix k.

Després, k passa per HKDF i alimenta AES-GCM: la part simètrica no canvia en res. Fixa't: DH permet patrons que un KEM no dona directament (totes dues parts contribueixen entropia de forma simètrica), i per això TLS ha hagut d'adaptar el seu handshake per tractar l'intercanvi com a encapsulació. Però per al patró "xifra cap a una clau pública" — el nostre sobre— el KEM encaixa de forma natural: on el sobre 0x02 feia "X25519 efímer + HKDF", el sobre post-quàntic farà "encaps + HKDF".

La PQC no surt de franc: les claus i signatures engreixen. Aquesta taula és la que explica per què la migració requereix enginyeria i no només un pip install (xifres dels nivells de seguretat habituals — ML-KEM-768, ML-DSA-65, SLH-DSA-SHA2-128s):

Lectures pràctiques: un ML-KEM al handshake TLS afegeix ~2 KB — es nota poc i per això ja està desplegat. Una cadena de certificats on cada signatura pesa 3-8 KB en lloc de 64-384 B és una altra història: certificats de desenes de KB, i per això la migració de la PKI (mòdul 5) serà la part lenta del procés mundial. Un JWT signat amb ML-DSA passa d'uns ~300 bytes a uns ~5 KB — cap en una capçalera HTTP, però deixa de ser "lleuger".

Els algorismes de reticles tenen una dècada llarga d'anàlisi; X25519 té un quart de segle. I si ML-KEM amaga una debilitat clàssica encara no descoberta (com li va passar a SIKE)? La resposta del consens actual és no triar: híbrid. S'executen tots dos intercanvis i es deriven les claus de la concatenació dels dos secrets:

La propietat és la que importa: si qualsevol dels dos aguanta, la sessió aguanta. Un criptoanàlisi clàssic d'ML-KEM no et despulla (X25519 sosté); el futur ordinador quàntic tampoc (ML-KEM sosté). Només caus si cauen tots dos.

I això no és teoria de laboratori: el grup X25519MLKEM768 ja es negocia per defecte entre els navegadors majoritaris i els grans CDN des de 2024-2025. Ho pots comprovar tu mateix: obre les eines de desenvolupador del navegador en un lloc web gran i mira el detall de seguretat de la connexió. Part del TLS 1.3 que vam estudiar a 05-02 ja és post-quàntic a l'intercanvi de claus — l'actualització te la porta l'evolució d'OpenSSL/BoringSSL i el teu servidor web, no el teu codi d'aplicació. Les signatures dels certificats, en canvi, continuen sent clàssiques: la confidencialitat ja es protegeix (contra harvest-now), l'autenticitat migrarà després — coherent amb la regla de la secció 2.

Toca saldar l'última reserva del curs. El sobre de medinube/sobre.py (04-05) versiona el seu primer byte: 0x01 = RSA-OAEP, 0x02 = X25519-ECIES, 0x03 = reservat. El disseny conceptual del 0x03 és un sobre híbrid clàssic + PQ:

Peces conegudes, una novetat: el receptor publica ara dues claus públiques (X25519 + ML-KEM); l'emissor fa l'ECDH efímer de sempre i una encapsulació, i HKDF barreja tots dos secrets. L'AES-GCM final és idèntic al de 0x02. La capçalera creix ~1,1 KB per sobre: irrellevant davant d'un historial.

Honestedat sobre l'estat de l'ecosistema: avui dia, pyca/cryptography — la nostra llibreria de capçalera— està incorporant ML-KEM/ML-DSA però el suport encara s'està assentant, i les alternatives (liboqs-python, wrappers diversos) evolucionen ràpid. Per això presentem el 0x03 com a disseny esbossat, no com a codi de producció: MediNube deixa el format definit i la decisió documentada, i implementarà quan la seva llibreria de referència ho ofereixi de forma estable. Això també és una lliçó: en criptografia, arribar el primer amb una implementació immadura és pitjor que arribar segon amb una de sòlida (regla 1, en la seva versió "tampoc integris tu el que encara no està llest").

Res de pànic i res d'heroisme. La llista realista, i veuràs que gairebé tota ja està feta:

1. Inventari criptogràfic: saber exactament quins algorismes, claus i formats es fan servir i on. És literalment la taula de 06-01 més la columna "sobreviu?" d'aquesta lliçó. Sense inventari no hi ha pla de migració — i les guies oficials (NIST, ENISA) comencen totes per aquí.
2. Criptoagilitat: la regla d'or 8 cobrant-se per segona vegada en aquest mòdul. Migrar a PQC serà canviar 0x02 per 0x03, v2 per v3, un kid per un altre — perquè tots els nostres formats porten versió. Un sistema sense versionat afronta la migració PQC reescrivint-se; MediNube l'afronta amb un byte.
3. Vigilar TLS i llibreries: mantenir OpenSSL/nginx/requests al dia ja ens dona l'híbrid en trànsit, que és el front urgent (harvest-now). Afegir al monitor de 05-03 la comprovació de quins grups negocien els nostres endpoints.
4. Simètrica ja dimensionada: AES-256 i SHA-256 des del mòdul 2-3. Aquí no cal tocar res — la decisió "256 bits, estàndard" de la regla 5 era també una decisió post-quàntica sense saber-ho.
5. No entrar en pànic ni comprar fum: desconfia de qui vengui "seguretat quàntica" amb urgència comercial. El calendari el marquen els estàndards i les llibreries serioses, no el màrqueting.

Què migra primer? El criteri ja el tens: vida útil del secret i cost del canvi.

Fixa't en l'última fila: l'arquitectura de vides curtes de 05-03 i 06-03 resulta ser també una defensa post-quàntica. Els bons principis es paguen sols diverses vegades.

• Error: "l'ordinador quàntic trencarà tot el xifratge". No: trenca l'asimètrica actual (Shor). AES-256, SHA-256, HMAC i Argon2 sobreviuen amb marge. Precisió per damunt de tot — també quan ho expliquis a direcció.
• Error: esperar que l'amenaça sigui tangible. Per a dades amb dècades de confidencialitat, el harvest-now fa que el xifratge clàssic d'avui sigui la bretxa de demà. La urgència depèn de la vida útil de la dada, no de la data del primer qubit útil.
• Error: migrar a PQC pura "per anar per davant". El consens és híbrid justament perquè els algorismes nous tenen menys rodatge; SIKE va caure sent finalista. Que un algorisme sigui post-quàntic no el fa immune al criptoanàlisi clàssic.
• Error: implementar Kyber a mà d'un paper (o d'un gist). La regla 1 no caduca en el futur: espera pyca/cryptography o fes servir bindings mantinguts d'implementacions auditades.
• Consell: mesura la teva criptoagilitat amb una pregunta: "quants llocs he de tocar per canviar d'algorisme de signatura?". Si la resposta és "un: el registre de versions/kid", estàs a punt per a aquesta dècada.

1. Triatge post-quàntic: classifica aquests cinc elements de MediNube per urgència de migració PQC (ja / curt / mitjà / últim) i justifica-ho amb el criteri vida-útil-del-secret: (a) el TLS de api.medinube.example; (b) les còpies de seguretat xifrades amb sobre 0x02 que es guarden 25 anys; (c) els JWT del portal (exp 15 min); (d) les signatures Ed25519 de receptes amb validesa de 30 dies; (e) els webhooks HMAC-SHA256.
2. El sobre 0x03 sobre el paper: sense escriure codi de producció, especifica el desxifrar del sobre híbrid: quins camps s'extreuen del blob (amb els seus offsets, sabent que la pública X25519 ocupa 32 B, la càpsula ML-KEM-768 1088 B i el nonce 12 B), quines dues operacions produeixen k1 i k2, i per què l'info de l'HKDF ha de ser diferent del de 0x02.
3. Explica-l'ho a direcció: escriu (5-7 línies) el resum executiu que enviaries a la direcció de MediNube justificant el pla post-quàntic: l'amenaça, per què afecta les dades sanitàries encara que l'ordinador quàntic no existeixi encara, què s'ha fet ja i què es farà. Sense argot: ni "reticles" ni "Shor".

1. (a) Ja: canal que transporta historials → harvest-now; a més és barat (actualitzar la pila TLS a l'híbrid). (b) Ja/curt: és el cas més greu — 25 anys de vida útil i protecció asimètrica clàssica; tan aviat com el 0x03 sigui implementable, rexifrar els sobres (la clau simètrica interior ja és AES-256: només es refà la capa de sobre). (c) Últim: 15 minuts de vida; cap adversari de 2040 hi guanya res. (d) Mitjà: 30 dies és curt, però les receptes arxivades potser han de tornar-se a verificar anys després davant disputes — si és així, pugen a mitjà termini amb segell de temps; si només es verifiquen en dispensar, baixa la urgència. La pregunta correcta és "quan es verifica per última vegada?". (e) Últim o mai: HMAC és simètric, Grover a penes el toca; amb clau de 256 bits està a punt tal com és.
2. Estructura: blob[0] == 0x03 (si no, delegar als desxifradors 0x01/0x02 — criptoagilitat); pub_efimera = blob[1:33]; capsula = blob[33:1121]; nonce = blob[1121:1133]; ct = blob[1133:]. Operacions: k1 = X25519(privada_x25519_receptor, pub_efimera); k2 = decaps(privada_mlkem_receptor, capsula); clau = HKDF-SHA256(k1 || k2, info=b"medinube:sobre:v3"); AESGCM(clau).decrypt(nonce, ct, aad). L'info diferent (v3 ≠ v2) aplica la separació de dominis de 02-04: encara que per qualsevol accident els secrets coincidissin amb els d'un altre context, les claus derivades serien diferents; cap clau es comparteix entre formats.
3. Exemple: "Els ordinadors quàntics, previstos per d'aquí una o dues dècades, podran desxifrar la tecnologia d'intercanvi de claus i signatura que avui protegeix Internet. No és un problema futur: un atacant pot gravar avui el nostre trànsit xifrat i desxifrar-lo llavors, i els nostres historials han de romandre confidencials durant dècades, com exigeix el RGPD per a dades de salut. Ja hem fet l'essencial: el nostre xifratge d'emmagatzematge fa servir algorismes que resisteixen aquesta amenaça, i tota la nostra criptografia està versionada, de manera que canviar d'algorisme és una actualització controlada i no una reescriptura. Els propers passos: activar el mode híbrid resistent-a-quàntic a les nostres connexions (ja estàndard als navegadors) i actualitzar el format dels nostres arxius de llarga durada quan les llibreries estiguin madures, previsiblement dins del cicle normal de manteniment."

I amb el byte 0x03 esbossat, no queda cap promesa oberta. És un bon moment per mirar enrere, perquè el viatge de MediNube és el teu viatge.

Vam començar al mòdul 1 amb un portal que confonia codificar amb xifrar: un token Base64 editable, claus d'API en un diccionari del codi, tokens de recuperació sortits de random. Allà vas aprendre les 9 regles d'or i a distingir l'objectiu de l'eina. Al mòdul 2 els historials d'Ana Pérez van passar a viatjar en AES-256-GCM amb AAD i un byte de versió que aleshores semblava burocràcia. El mòdul 3 va portar la integritat: webhooks amb HMAC i finestra anti-replay, contrasenyes amb Argon2id, tokens desats com a hashes. El mòdul 4 va obrir el món asimètric: la Dra. Ferrer signant receptes amb Ed25519, X25519 donant forward secrecy, i el sobre híbrid amb els seus bytes de versió. El mòdul 5 va convertir les claus públiques en identitats: certificats, la mini-PKI, TLS 1.3, mTLS per a les clíniques, i la lliçó de l'incident — la clau que va caure per un git push. I aquest mòdul 6 ho ha portat tot al desenvolupament real: els secrets al gestor amb envelope encryption, el mapa de xifratge per capes amb verify-full fins i tot a la base de dades, el vell token Base64 convertit en JWT EdDSA amb kid, la mirada d'auditor sobre tots els _MALAMENT, i avui, el pla per a l'única amenaça que encara no existeix.

Fixa't en el que es repeteix: gairebé res del que va fer millor MediNube va ser una primitiva més forta. Va ser fer servir bé el que ja existia: versionar formats, separar claus per propòsit, caducar ràpid, verificar sempre, no inventar, comparar en temps constant, assumir que l'enemic llegeix el teu repositori. Les 9 regles d'or del primer dia són el llegat del curs: torna-hi cada vegada que revisis codi — avui has vist que fins i tot la migració post-quàntica és, en el fons, la regla 8 ben aplicada.

Per seguir creixent des d'aquí: practica deliberadament — els reptes de cryptopals et faran trencar el que aquí has après a construir, que és l'altra meitat de l'enteniment; llegeix post-mortems d'incidents criptogràfics reals (els de les CA, els de JWT, els de nonces reutilitzats: cadascun és una lliçó d'aquesta galeria amb noms i dates); segueix les llibreries que fas servir (els changelogs de pyca/cryptography i OpenSSL són un curs continu); i mantén l'inventari i la llista de verificació vius als teus projectes, perquè la criptografia s'espatlla per detalls mundans quan ningú no mira.

Això és tot. MediNube queda en bones mans: les teves. Gràcies per arribar fins aquí — i que els teus nonces siguin sempre únics.