Última lección del curso, y empieza con una confesión pendiente desde el módulo 4: cuando diseñamos el sobre híbrido de MediNube reservamos el byte 0x03 "para el futuro". Ese futuro tiene nombre: criptografía post-cuántica (PQC). En esta lección vas a entender qué amenaza exactamente un ordenador cuántico (y qué no — hay mucho ruido), por qué "harvest now, decrypt later" convierte esto en un problema de hoy para historiales médicos que deben ser confidenciales durante décadas, quiénes son los algoritmos elegidos por el NIST (ML-KEM, ML-DSA, SLH-DSA), por qué el mundo está migrando en modo híbrido, y qué debe hacer MediNube ya — spoiler: la mayor parte del trabajo lo hicimos en 06-01 sin saberlo. Y al final, cerraremos el curso mirando el camino recorrido.

1. Qué amenaza un ordenador cuántico (y qué no)
2. Harvest now, decrypt later: por qué esto va de hoy
3. El proceso NIST y los elegidos: ML-KEM, ML-DSA, SLH-DSA
4. Qué es un KEM (y en qué se diferencia de Diffie-Hellman)
5. El precio en bytes: tamaños comparados
6. La estrategia híbrida: X25519 + ML-KEM
7. El byte 0x03: el sobre post-cuántico de MediNube
8. Qué debe hacer MediNube hoy
9. Cronología orientativa de migración

Dos algoritmos cuánticos importan aquí, y hacen cosas muy distintas:

• Shor (1994): resuelve en tiempo eficiente la factorización de enteros y el logaritmo discreto (también en curvas elípticas). Es decir: un ordenador cuántico suficientemente grande rompe RSA, Diffie-Hellman y toda la criptografía de curva elíptica — Ed25519, X25519, P-256, P-384. No las debilita: las rompe del todo. Toda la asimétrica del módulo 4 y las firmas de los certificados del módulo 5 están en la lista.
• Grover (1996): acelera la búsqueda por fuerza bruta de forma cuadrática: buscar entre 2¹²⁸ posibilidades cuesta "solo" ~2⁶⁴ operaciones cuánticas. Contra la criptografía simétrica y los hashes no hay atajo estructural, solo esta aceleración: la defensa es doblar el tamaño. AES-256 mantiene ~128 bits de seguridad post-cuántica; SHA-256 sigue siendo sólido para lo que lo usamos. (Y en la práctica, Grover paraleliza tan mal que muchos criptógrafos lo consideran aún menos amenazante que su cota teórica.)

Apliquémoslo al arsenal que MediNube ha construido durante el curso:

El patrón es nítido: la simétrica y los hashes aguantan; la asimétrica cae entera. Por eso la PQC no toca AES ni SHA-2: reemplaza el intercambio de claves y las firmas.

Honestidad sobre el "cuándo": hoy no existe ningún ordenador cuántico capaz de ejecutar Shor sobre claves reales (se necesitan millones de qubits físicos con corrección de errores; los actuales tienen miles, ruidosos). Las estimaciones serias hablan de una posibilidad real en 10-20 años, con enorme incertidumbre. Entonces, ¿por qué no esperar?

Porque el atacante no necesita el ordenador cuántico hoy: le basta con grabar hoy y descifrar mañana. Es la estrategia harvest now, decrypt later: capturar tráfico TLS cifrado (o robar blobs asimétricos en reposo) y almacenarlo pacientemente hasta que Shor sea ejecutable. Todo lo que hoy viaja protegido solo por X25519 o RSA quedará retroactivamente expuesto.

La pregunta de diseño es: ¿cuánto tiempo deben permanecer confidenciales tus datos? Y aquí MediNube es el caso perfecto, casi de libro:

• Un historial médico debe ser confidencial durante décadas — la vida del paciente y más allá. El historial de Ana Pérez interceptado hoy en tránsito y descifrado en 2040 es una brecha real de 2040 con datos capturados en 2026.
• El RGPD no caduca con la tecnología: los datos de salud son categoría especial (art. 9), y "medidas técnicas apropiadas" (art. 32) se interpreta contra el estado del arte del momento del tratamiento y del riesgo previsible. La amenaza cuántica ya es riesgo previsible documentado por ENISA, NIST y las agencias europeas.
• En cambio, un JWT con exp de 15 minutos o un webhook con ventana de 300 s no le interesan a nadie en 2040: la vida útil del secreto define la urgencia.

Esta asimetría produce la regla práctica de toda la lección: primero los canales que transportan datos longevos (confidencialidad), después las firmas (autenticidad). Una firma solo necesita ser segura en el momento de verificarse; un secreto necesita serlo durante toda su vida.

¿De dónde salen los algoritmos post-cuánticos? De un concurso público: el NIST abrió en 2016 una competición mundial — 82 candidatos, años de análisis abierto, rondas eliminatorias donde criptógrafos de todo el planeta intentaron romper los diseños de sus competidores (y varios cayeron de forma espectacular: SIKE, finalista, fue roto en 2022 con un portátil). Es Kerckhoffs institucionalizado, otra vez: la confianza no viene de la ocultación sino de años de escrutinio público fallido. Exactamente como AES en 1997-2001.

Los estándares publicados (2024), con su nombre de concurso entre paréntesis:

• ML-KEM (Kyber) — FIPS 203: encapsulación de claves (KEM), el sustituto del intercambio de claves. Basado en retículos (lattices, problema Module-LWE). Es el caballo de batalla: rápido, tamaños razonables.
• ML-DSA (Dilithium) — FIPS 204: firmas digitales, también sobre retículos. El sustituto general de RSA-PSS/Ed25519 para firmar.
• SLH-DSA (SPHINCS+) — FIPS 205: firmas basadas solo en hashes. Conservador al máximo: su seguridad se apoya en SHA-2/SHAKE, la parte del arsenal que ya sabemos que sobrevive. El precio: firmas enormes y lentas. Es el "plan B" por si los retículos deparan sorpresas, y la opción para firmas de larguísima vida (firmware, raíces de confianza).

ML-KEM no es "un Diffie-Hellman post-cuántico": es un KEM (Key Encapsulation Mechanism), y la diferencia de forma importa para integrarlo. Recuerda el ECDH de 04-04: las dos partes aportan su par de claves, ambas ejecutan la misma operación y llegan al mismo secreto — es simétrico en su coreografía. Un KEM es asimétrico también en la coreografía, y en realidad ya lo conoces, porque es la forma de nuestro sobre híbrido de 04-05:

1. keygen() → el receptor (MediNube) publica su clave pública de encapsulación.
2. encaps(publica) → el emisor genera a la vez un secreto compartido k y un ciphertext c (la "cápsula") y envía c. No elige k: el algoritmo lo produce.
3. decaps(privada, c) → el receptor recupera el mismo k.

Después, k pasa por HKDF y alimenta AES-GCM: la parte simétrica no cambia en nada. Fíjate: DH permite patrones que un KEM no da directamente (ambas partes contribuyen entropía de forma simétrica), y por eso TLS ha tenido que adaptar su handshake para tratar el intercambio como encapsulación. Pero para el patrón "cifra hacia una clave pública" — nuestro sobre — el KEM es un encaje natural: donde el sobre 0x02 hacía "X25519 efímero + HKDF", el sobre post-cuántico hará "encaps + HKDF".

La PQC no sale gratis: las claves y firmas engordan. Esta tabla es la que explica por qué la migración requiere ingeniería y no solo un pip install (cifras de los niveles de seguridad habituales — ML-KEM-768, ML-DSA-65, SLH-DSA-SHA2-128s):

Lecturas prácticas: un ML-KEM en el handshake TLS añade ~2 KB — se nota poco y por eso ya está desplegado. Una cadena de certificados donde cada firma pesa 3-8 KB en vez de 64-384 B es otra historia: certificados de decenas de KB, y por eso la migración de la PKI (módulo 5) será la parte lenta del proceso mundial. Un JWT firmado con ML-DSA pasa de ~300 bytes a ~5 KB — cabe en una cabecera HTTP, pero deja de ser "ligero".

Los algoritmos de retículos tienen una década larga de análisis; X25519 tiene un cuarto de siglo. ¿Y si ML-KEM esconde una debilidad clásica aún no descubierta (como le pasó a SIKE)? La respuesta del consenso actual es no elegir: híbrido. Se ejecutan ambos intercambios y se derivan las claves de la concatenación de los dos secretos:

La propiedad es la que importa: si cualquiera de los dos aguanta, la sesión aguanta. Un criptoanálisis clásico de ML-KEM no te desnuda (X25519 sostiene); el futuro ordenador cuántico tampoco (ML-KEM sostiene). Solo caes si caen ambos.

Y esto no es teoría de laboratorio: el grupo X25519MLKEM768 ya se negocia por defecto entre los navegadores mayoritarios y los grandes CDNs desde 2024-2025. Puedes comprobarlo tú mismo: abre las herramientas de desarrollo del navegador en una web grande y mira el detalle de seguridad de la conexión. Parte del TLS 1.3 que estudiamos en 05-02 ya es post-cuántico en el intercambio de claves — la actualización te la trae la evolución de OpenSSL/BoringSSL y tu servidor web, no tu código de aplicación. Las firmas de los certificados, en cambio, siguen siendo clásicas: la confidencialidad ya se protege (contra harvest-now), la autenticidad migrará después — coherente con la regla de la sección 2.

Toca saldar la última reserva del curso. El sobre de medinube/sobre.py (04-05) versiona su primer byte: 0x01 = RSA-OAEP, 0x02 = X25519-ECIES, 0x03 = reservado. El diseño conceptual del 0x03 es un sobre híbrido clásico + PQ:

Piezas conocidas, una novedad: el receptor publica ahora dos claves públicas (X25519 + ML-KEM); el emisor hace el ECDH efímero de siempre y una encapsulación, y HKDF mezcla ambos secretos. El AES-GCM final es idéntico al de 0x02. La cabecera crece ~1.1 KB por sobre: irrelevante frente a un historial.

Honestidad sobre el estado del ecosistema: a día de hoy, pyca/cryptography — nuestra librería de cabecera — está incorporando ML-KEM/ML-DSA pero el soporte aún se está asentando, y las alternativas (liboqs-python, wrappers varios) evolucionan rápido. Por eso presentamos el 0x03 como diseño esbozado, no como código de producción: MediNube deja el formato definido y la decisión documentada, e implementará cuando su librería de referencia lo ofrezca de forma estable. Esto también es una lección: en criptografía, llegar el primero con una implementación inmadura es peor que llegar segundo con una sólida (regla 1, en su versión "tampoco integres tú lo que aún no está listo").

Nada de pánico y nada de heroísmo. La lista realista, y verás que casi toda está ya hecha:

1. Inventario criptográfico: saber exactamente qué algoritmos, claves y formatos se usan y dónde. Es literalmente la tabla de 06-01 más la columna "¿sobrevive?" de esta lección. Sin inventario no hay plan de migración — y las guías oficiales (NIST, ENISA) empiezan todas por aquí.
2. Criptoagilidad: la regla de oro 8 cobrándose por segunda vez en este módulo. Migrar a PQC será cambiar 0x02 por 0x03, v2 por v3, un kid por otro — porque todos nuestros formatos llevan versión. Un sistema sin versionado afronta la migración PQC reescribiéndose; MediNube la afronta con un byte.
3. Vigilar TLS y librerías: mantener OpenSSL/nginx/requests al día ya nos da el híbrido en tránsito, que es el frente urgente (harvest-now). Añadir al monitor de 05-03 la comprobación de qué grupos negocian nuestros endpoints.
4. Simétrica ya dimensionada: AES-256 y SHA-256 desde el módulo 2-3. Aquí no hay que tocar nada — la decisión "256 bits, estándar" de la regla 5 era también una decisión post-cuántica sin saberlo.
5. No entrar en pánico ni comprar humo: desconfía de quien venda "seguridad cuántica" con urgencia comercial. El calendario lo marcan los estándares y las librerías serias, no el marketing.

¿Qué migra primero? El criterio ya lo tienes: vida útil del secreto y coste del cambio.

Fíjate en la última fila: la arquitectura de vidas cortas de 05-03 y 06-03 resulta ser también una defensa post-cuántica. Los buenos principios se pagan solos varias veces.

• Error: "el ordenador cuántico romperá todo el cifrado". No: rompe la asimétrica actual (Shor). AES-256, SHA-256, HMAC y Argon2 sobreviven con margen. Precisión ante todo — también cuando se lo expliques a dirección.
• Error: esperar a que la amenaza sea tangible. Para datos con décadas de confidencialidad, el harvest-now hace que el cifrado clásico de hoy sea la brecha de mañana. La urgencia depende de la vida útil del dato, no de la fecha del primer qubit útil.
• Error: migrar a PQC pura "para ir por delante". El consenso es híbrido justamente porque los algoritmos nuevos tienen menos rodaje; SIKE cayó siendo finalista. Que un algoritmo sea post-cuántico no lo hace inmune al criptoanálisis clásico.
• Error: implementar Kyber a mano de un paper (o de un gist). La regla 1 no caduca en el futuro: espera a pyca/cryptography o usa bindings mantenidos de implementaciones auditadas.
• Consejo: mide tu criptoagilidad con una pregunta: "¿cuántos sitios tengo que tocar para cambiar de algoritmo de firma?". Si la respuesta es "uno: el registro de versiones/kid", estás listo para esta década.

1. Triaje post-cuántico: clasifica estos cinco elementos de MediNube por urgencia de migración PQC (ya / corto / medio / último) y justifica con el criterio vida-útil-del-secreto: (a) el TLS de api.medinube.example; (b) los backups cifrados con sobre 0x02 que se guardan 25 años; (c) los JWT del portal (exp 15 min); (d) las firmas Ed25519 de recetas con validez de 30 días; (e) los webhooks HMAC-SHA256.
2. El sobre 0x03 sobre el papel: sin escribir código de producción, especifica el descifrar del sobre híbrido: qué campos se extraen del blob (con sus offsets, sabiendo que la pública X25519 ocupa 32 B, la cápsula ML-KEM-768 1088 B y el nonce 12 B), qué dos operaciones producen k1 y k2, y por qué el info del HKDF debe ser distinto del de 0x02.
3. Explícaselo a dirección: escribe (5-7 líneas) el resumen ejecutivo que enviarías a la dirección de MediNube justificando el plan post-cuántico: la amenaza, por qué afecta a datos sanitarios aunque el ordenador cuántico no exista aún, qué se ha hecho ya y qué se hará. Sin jerga: ni "retículos" ni "Shor".

1. (a) Ya: canal que transporta historiales → harvest-now; además es barato (actualizar la pila TLS al híbrido). (b) Ya/corto: es el caso más grave — 25 años de vida útil y protección asimétrica clásica; en cuanto el 0x03 sea implementable, recifrar los sobres (la clave simétrica interior ya es AES-256: solo se rehace la capa de sobre). (c) Último: 15 minutos de vida; ningún adversario de 2040 gana nada. (d) Medio: 30 días es corto, pero las recetas archivadas quizá deban re-verificarse años después ante disputas — si es así, suben a medio plazo con sello de tiempo; si solo se verifican al dispensar, baja la urgencia. La pregunta correcta es "¿cuándo se verifica por última vez?". (e) Último o nunca: HMAC es simétrico, Grover apenas lo roza; con clave de 256 bits está listo tal cual.
2. Estructura: blob[0] == 0x03 (si no, delegar en los descifradores 0x01/0x02 — criptoagilidad); pub_efimera = blob[1:33]; capsula = blob[33:1121]; nonce = blob[1121:1133]; ct = blob[1133:]. Operaciones: k1 = X25519(privada_x25519_receptor, pub_efimera); k2 = decaps(privada_mlkem_receptor, capsula); clave = HKDF-SHA256(k1 || k2, info=b"medinube:sobre:v3"); AESGCM(clave).decrypt(nonce, ct, aad). El info distinto (v3 ≠ v2) aplica la separación de dominios de 02-04: aunque por cualquier accidente los secretos coincidieran con los de otro contexto, las claves derivadas serían distintas; ninguna clave se comparte entre formatos.
3. Ejemplo: "Los ordenadores cuánticos, previstos para dentro de una o dos décadas, podrán descifrar la tecnología de intercambio de claves y firma que hoy protege Internet. No es un problema futuro: un atacante puede grabar hoy nuestro tráfico cifrado y descifrarlo entonces, y nuestros historiales deben permanecer confidenciales durante décadas, como exige el RGPD para datos de salud. Ya hemos hecho lo esencial: nuestro cifrado de almacenamiento usa algoritmos que resisten esta amenaza, y toda nuestra criptografía está versionada, de modo que cambiar de algoritmo es una actualización controlada y no una reescritura. Los próximos pasos: activar el modo híbrido resistente-a-cuántica en nuestras conexiones (ya estándar en los navegadores) y actualizar el formato de nuestros archivos de larga duración cuando las librerías estén maduras, previsiblemente dentro del ciclo normal de mantenimiento."

Y con el byte 0x03 esbozado, no queda ninguna promesa abierta. Es un buen momento para mirar atrás, porque el viaje de MediNube es tu viaje.

Empezamos en el módulo 1 con un portal que confundía codificar con cifrar: un token Base64 editable, claves de API en un diccionario del código, tokens de recuperación salidos de random. Allí aprendiste las 9 reglas de oro y a distinguir el objetivo de la herramienta. En el módulo 2 los historiales de Ana Pérez pasaron a viajar en AES-256-GCM con AAD y un byte de versión que entonces parecía burocracia. El módulo 3 trajo la integridad: webhooks con HMAC y ventana anti-replay, contraseñas con Argon2id, tokens guardados como hashes. El módulo 4 abrió el mundo asimétrico: la Dra. Ferrer firmando recetas con Ed25519, X25519 dando forward secrecy, y el sobre híbrido con sus bytes de versión. El módulo 5 convirtió las claves públicas en identidades: certificados, la mini-PKI, TLS 1.3, mTLS para las clínicas, y la lección del incidente — la clave que cayó por un git push. Y este módulo 6 llevó todo al desarrollo real: los secretos al gestor con envelope encryption, el mapa de cifrado por capas con verify-full hasta en la base de datos, el viejo token Base64 convertido en JWT EdDSA con kid, la mirada de auditor sobre todos los _MAL, y hoy, el plan para la única amenaza que aún no existe.

Fíjate en lo que se repite: casi nada de lo que hizo mejor a MediNube fue una primitiva más fuerte. Fue usar bien lo que ya existía: versionar formatos, separar claves por propósito, caducar rápido, verificar siempre, no inventar, comparar en tiempo constante, asumir que el enemigo lee tu repo. Las 9 reglas de oro del primer día son el legado del curso: vuelve a ellas cada vez que revises código — hoy has visto que hasta la migración post-cuántica es, en el fondo, la regla 8 bien aplicada.

Para seguir creciendo desde aquí: practica deliberadamente — los retos de cryptopals te harán romper lo que aquí aprendiste a construir, que es la otra mitad del entendimiento; lee post-mortems de incidentes criptográficos reales (los de las CAs, los de JWT, los de nonces reutilizados: cada uno es una lección de esta galería con nombres y fechas); sigue las librerías que usas (los changelogs de pyca/cryptography y OpenSSL son un curso continuo); y mantén el inventario y la checklist vivos en tus proyectos, porque la criptografía se estropea por detalles mundanos cuando nadie mira.

Eso es todo. MediNube queda en buenas manos: las tuyas. Gracias por llegar hasta aquí — y que tus nonces sean siempre únicos.