El TLS post-cuántico es HTTPS que se mantiene seguro incluso frente a un atacante que disponga de un gran ordenador cuántico. Reemplaza las matemáticas que sustentan el intercambio de claves actual —que un ordenador cuántico podría romper— por algoritmos diseñados para resistir los ataques cuánticos.
Esto no es un proyecto de investigación lejano. A mediados de 2026, más del 65% del tráfico web humano que pasa por Cloudflare ya está cifrado de forma post-cuántica, y Chrome, Edge y Firefox negocian por defecto un intercambio de claves resistente a la computación cuántica siempre que el servidor lo admita. Si has visitado Google recientemente desde un navegador moderno, es casi seguro que has usado TLS post-cuántico sin darte cuenta.
Por qué el TLS clásico está en riesgo
El TLS actual se apoya en dos tipos de matemáticas de clave pública:
- Intercambio de claves (ECDHE, usando X25519 o P-256): acuerda un secreto compartido a través de un canal abierto.
- Firmas (RSA, ECDSA): demuestra que el certificado es auténtico.
Ambos dependen de problemas que resultan difíciles para los ordenadores clásicos: factorizar números grandes (RSA) y el logaritmo discreto en curvas elípticas (ECC). El algoritmo de Shor, ejecutándose en un ordenador cuántico suficientemente grande, resuelve ambos de forma eficiente. Todavía no existe un «ordenador cuántico criptográficamente relevante» (CRQC), pero el campo avanza tan rápido que la planificación ha pasado de «si ocurre» a «cuándo ocurra».
Criptografía de clave pública → explica las matemáticas subyacentes que amenazan los ordenadores cuánticos.
«Cosechar ahora, descifrar después»: por qué esto es urgente hoy
Podrías pensar que no hay prisa: ningún ordenador cuántico puede romper el TLS hoy, así que ¿para qué cambiar ahora?
La amenaza es cosechar ahora, descifrar después (harvest now, decrypt later, HNDL). Un adversario graba tu tráfico cifrado hoy y lo almacena. Cuando un ordenador cuántico esté disponible —posiblemente en la década de 2030—, descifra retroactivamente el tráfico almacenado.
Esto hace que el plazo límite para el intercambio de claves sea mucho más temprano que la llegada de los ordenadores cuánticos. Cualquier dato con una vida útil de confidencialidad larga —historiales médicos, datos financieros, secretos gubernamentales, código fuente, credenciales— necesita cifrado resistente a la computación cuántica ahora, porque la grabación ya está ocurriendo.
El intercambio de claves es urgente. Las firmas, menos. No puedes falsificar retroactivamente una firma sobre tráfico que ya ocurrió: una firma solo necesita ser resistente a la computación cuántica antes de que existan los ordenadores cuánticos, no antes de eso. Por eso la industria desplegó primero el intercambio de claves post-cuántico.
Los estándares: ML-KEM y ML-DSA
En agosto de 2024, el NIST publicó los primeros estándares post-cuánticos finalizados:
| Estándar | Nombre | Función | Reemplaza a |
|---|---|---|---|
| FIPS 203 | ML-KEM (antes Kyber) | Encapsulado de claves (intercambio de claves) | Intercambio de claves ECDHE / RSA |
| FIPS 204 | ML-DSA (antes Dilithium) | Firmas digitales | Firmas RSA / ECDSA |
| FIPS 205 | SLH-DSA (SPHINCS+) | Firmas basadas en hash | Respaldo de firma conservador |
ML-KEM (Module-Lattice Key Encapsulation Mechanism, mecanismo de encapsulado de claves basado en retículos modulares) es el que ya está desplegado en TLS. Viene en tres tamaños: ML-KEM-512, ML-KEM-768 y ML-KEM-1024. ML-KEM-768 es el punto óptimo que se usa en la web.
Intercambio de claves híbrido: X25519MLKEM768
Los navegadores no abandonan la criptografía clásica para pasar a una solución puramente post-cuántica de un día para otro. Sería temerario: ML-KEM es nuevo, y un fallo podría romperlo todo. En su lugar, TLS 1.3 utiliza un intercambio de claves híbrido que combina un algoritmo clásico y uno post-cuántico.
El grupo con nombre que verás en 2026 es X25519MLKEM768:
X25519MLKEM768 = X25519 (ECDHE clásico) + ML-KEM-768 (post-cuántico)Los dos secretos compartidos se concatenan (32 bytes de X25519 + 32 bytes de ML-KEM = un secreto combinado de 64 bytes) y se introducen en el calendario de claves de TLS.
La garantía de seguridad es «seguro si cualquiera de los dos aguanta». Un atacante tiene que romper ambos, X25519 y ML-KEM-768, para recuperar la clave de sesión. Así que:
- Si resulta que ML-KEM-768 tiene un fallo → X25519 sigue protegiéndote (frente a atacantes clásicos).
- Si un ordenador cuántico rompe X25519 → ML-KEM-768 sigue protegiéndote.
Este diseño de doble seguridad es la razón por la que el modo híbrido es el predeterminado en todas partes, y no el modo puramente post-cuántico.
Dónde encaja en el handshake
El intercambio de claves híbrido utiliza el mismo handshake de TLS 1.3 descrito en Qué es TLS 1.3 →. La única diferencia es el key_share: el ClientHello transporta un key share X25519MLKEM768 en lugar de uno X25519 sencillo. Las claves de ML-KEM son más grandes (~1,2 KB frente a 32 bytes), así que el ClientHello crece alrededor de un kilobyte —normalmente algo insignificante, aunque en ocasiones puede desbordar los límites de los paquetes en redes restringidas.
También sigue proporcionándote secreto hacia adelante →: un par de claves nuevo por conexión, en su edición post-cuántica.
Qué ya está desplegado en 2026
| Componente | Estado post-cuántico (mediados de 2026) |
|---|---|
| Chrome / Edge | X25519MLKEM768 negociado por defecto |
| Firefox | X25519MLKEM768 admitido y habilitado |
| Cloudflare | Más del 65% del tráfico humano cifrado de forma PQ; intercambio de claves resuelto |
| Sirve intercambio de claves post-cuántico | |
| AWS | ML-KEM en KMS, ACM y Secrets Manager; retira el Kyber heredado en 2026 |
| OpenSSL 3.5+ | Soporte nativo de ML-KEM y X25519MLKEM768 |
| Java (SunJSSE) | X25519MLKEM768 habilitado por defecto |
La pieza que aún no está resuelta a gran escala son los certificados post-cuánticos: firmar certificados con ML-DSA en lugar de RSA/ECDSA. Las firmas y claves públicas de ML-DSA son mucho más grandes (kilobytes frente a ~64 bytes), lo que infla el handshake y tensiona los límites de tamaño de la cadena de certificados. Cloudflare planea usar ML-DSA en las conexiones de origen para mediados de 2026 y está explorando los Merkle Tree Certificates (certificados de árbol de Merkle) para mantener el tamaño manejable, con el objetivo de lograr un escenario plenamente post-cuántico (incluida la autenticación) para 2029.
Cómo comprobar si estás usando TLS post-cuántico
En el navegador
Abre cualquier sitio importante en Chrome → DevTools → pestaña Security → fíjate en los detalles de la conexión. Una conexión post-cuántica muestra un intercambio de claves como X25519MLKEM768 (o X25519Kyber768 en compilaciones más antiguas).
Con OpenSSL 3.5+
openssl s_client -connect cloudflare.com:443 -groups X25519MLKEM768 2>/dev/null | grep -i "Negotiated TLS1.3 group"
# Esperado: Negotiated TLS1.3 group: X25519MLKEM768Si obtienes un error o un grupo distinto, o bien tu OpenSSL es anterior a la versión 3.5, o bien el servidor todavía no ofrece intercambio de claves post-cuántico.
Comprueba tu versión de OpenSSL
openssl version
# Necesitas: OpenSSL 3.5+ para soporte nativo de X25519MLKEM768Cómo habilitarlo en tu servidor
Para la mayoría de los sitios, la respuesta es actualizar y no deshabilitarlo: el intercambio de claves híbrido post-cuántico se habilita automáticamente en cuanto tu pila lo admite.
Nginx / Apache
El intercambio de claves post-cuántico reside en tu biblioteca de TLS, no en la configuración del servidor web. Compila o ejecuta contra OpenSSL 3.5+ (o BoringSSL con ML-KEM). Una vez enlazado, X25519MLKEM768 se ofrece automáticamente junto a X25519, sin necesidad de ninguna directiva nueva. No fijes ssl_ecdh_curve a una única curva clásica, o excluirás el grupo híbrido.
Detrás de una CDN
La vía más sencilla: pon tu sitio detrás de Cloudflare (u otra CDN compatible con PQC). La conexión del navegador al borde de la red se vuelve post-cuántica de inmediato, sin cambios en tu origen. Así es como la mayor parte de ese 65% del tráfico se volvió resistente a la computación cuántica: los operadores no tocaron sus servidores de origen en absoluto.
Tu certificado todavía no cambia
No necesitas un certificado nuevo para el intercambio de claves post-cuántico. Tu certificado RSA o ECC actual funciona perfectamente: el intercambio de claves híbrido protege la sesión, mientras que el certificado, por ahora, sigue usando firmas clásicas. Los certificados post-cuánticos (ML-DSA) son una migración aparte y posterior.
Preguntas frecuentes
¿Necesito comprar un «certificado resistente a la computación cuántica» especial?
No. El intercambio de claves post-cuántico (la parte urgente) no toca tu certificado en absoluto: tu certificado RSA/ECC actual sigue funcionando. Cualquiera que venda hoy un «certificado SSL resistente a la computación cuántica» está haciendo sobre todo marketing; las firmas post-cuánticas (ML-DSA) en producción todavía no las emiten ampliamente las CA públicas.
¿Es el TLS post-cuántico más lento?
Apenas. ML-KEM-768 es rápido a nivel computacional —a menudo más rápido que ECDHE. El coste principal es el tamaño: los key shares más grandes añaden ~1 KB al handshake, lo que puede costar una vuelta de ida y vuelta adicional únicamente en redes con límites de paquete muy pequeños. Para casi todos los usuarios la diferencia es imperceptible.
¿Cuándo romperán realmente RSA los ordenadores cuánticos?
Nadie lo sabe. Las estimaciones creíbles van desde principios de la década de 2030 hasta «puede que nunca a gran escala». Pero, debido a la estrategia de cosechar ahora y descifrar después, el plazo límite de despliegue para el intercambio de claves ya ha llegado, que es precisamente la razón por la que los navegadores y las CDN se movieron en 2024-2026 en lugar de esperar.
¿Y qué pasa con TLS 1.2?
El intercambio de claves híbrido post-cuántico está definido solo para TLS 1.3. Esta es una razón más para habilitar TLS 1.3 →: es la única vía hacia un HTTPS resistente a la computación cuántica. TLS 1.2 no recibirá intercambio de claves post-cuántico.
¿Es ML-KEM lo mismo que Kyber?
Sí: ML-KEM es la versión estandarizada por el NIST del algoritmo antes llamado CRYSTALS-Kyber. Las compilaciones de navegador y las herramientas más antiguas muestran Kyber768; los despliegues estandarizados usan ML-KEM-768. Están estrechamente relacionados, pero no son idénticos bit a bit, así que un cliente con el estándar definitivo y un servidor previo al estándar pueden no llegar a negociar. Para 2026 el ecosistema se ha pasado en gran medida al ML-KEM definitivo.
¿Debería hacer algo ahora mismo?
Para un sitio web típico: asegúrate de estar en TLS 1.3, mantén tu biblioteca de TLS actualizada (OpenSSL 3.5+) y plantéate una CDN compatible con PQC si manejas datos sensibles de larga vida. Con eso basta para conseguir hoy un intercambio de claves resistente a la computación cuántica. Los certificados post-cuánticos pueden esperar a que maduren los estándares y las herramientas de las CA.