Criptografía post-cuántica:
qué cambia, qué no y cuándo migrar
Fundamentos de criptografía | unfantasmaenelsistema.com
Pocos temas de seguridad generan tanto ruido y tan poca información útil como la criptografía post-cuántica. Titulares que anuncian que «el cifrado está muerto», vendedores que ofrecen soluciones cuánticas para todo, y al mismo tiempo navegadores que ya han activado algoritmos nuevos sin que casi nadie se entere. La realidad es más tranquila y más concreta: un ordenador cuántico grande rompería una parte específica de la criptografía que usamos, esa parte ya tiene sustituto estandarizado, y hay cosas que puedes y debes hacer ahora aunque ese ordenador no exista todavía.
Este artículo explica qué rompe exactamente un ordenador cuántico y qué no, qué es «harvest now, decrypt later» y por qué te afecta hoy, los estándares que publicó el NIST en 2024, cómo se está desplegando todo esto en TLS y SSH, y qué pasos tiene sentido dar en una organización normal.
Qué aprenderás en este artículo
Qué algoritmos rompe el algoritmo de Shor (RSA, Diffie-Hellman, curva elíptica) y por qué · Por qué el cifrado simétrico y los hashes apenas se ven afectados (algoritmo de Grover) · «Harvest now, decrypt later»: la razón de que los datos de larga vida corran peligro ya · Los estándares NIST de 2024: ML-KEM (Kyber), ML-DSA (Dilithium) y SLH-DSA · Despliegue híbrido en TLS 1.3 (X25519 + ML-KEM) y qué navegadores y servidores ya lo traen · Qué puede hacer hoy una pyme: inventariar dónde se usa criptografía asimétrica y planificar
1. Qué rompe un ordenador cuántico (y qué no)
La amenaza no es genérica. Un ordenador cuántico con suficientes cúbits estables ejecutaría el algoritmo de Shor, que resuelve de forma eficiente los dos problemas matemáticos sobre los que se apoya toda la criptografía asimétrica actual: factorizar números grandes (RSA) y el logaritmo discreto (Diffie-Hellman y curva elíptica).
| Mecanismo | Se apoya en | Efecto de un ordenador cuántico |
|---|---|---|
| RSA (cifrado y firma) | Factorización | Roto por Shor |
| Diffie-Hellman / ECDH (acuerdo de clave) | Logaritmo discreto | Roto por Shor |
| ECDSA / EdDSA (firmas) | Logaritmo discreto en curvas | Roto por Shor |
| AES-128 / AES-256 (cifrado simétrico) | Búsqueda de clave por fuerza bruta | Grover reduce a la mitad la seguridad efectiva: AES-256 -> ~128 bits, sigue sobrado |
| SHA-256 / SHA-3 (hash) | Resistencia a preimagen y colisión | Grover debilita algo; se compensa con más longitud de salida. Sin urgencia |
La conclusión práctica: lo que hay que cambiar es la criptografía de clave pública —el intercambio de claves y las firmas—, no el cifrado simétrico que protege el grueso de los datos. Para el lado simétrico basta con usar AES-256 en lugar de AES-128 y hashes de 256 bits o más, cosa que ya se hace.
El ordenador cuántico criptográficamente relevante aún no existe
Los prototipos actuales tienen del orden de cientos a pocos miles de cúbits ruidosos; romper RSA-2048 requeriría millones de cúbits físicos con corrección de errores. Las estimaciones públicas hablan de una a dos décadas, con mucha incertidumbre. Eso no es motivo para ignorar el problema, por lo que explica la sección siguiente
2. «Harvest now, decrypt later»: por qué importa ya
Un adversario con recursos —una agencia estatal, por ejemplo— puede grabar hoy tráfico cifrado que no sabe leer, guardarlo, y descifrarlo dentro de diez o quince años cuando tenga la máquina. Para datos que dejan de importar en horas (una sesión de compra) esto es irrelevante. Para datos con vida larga, no:
- Historiales médicos, información genética
- Secretos industriales, patentes en trámite, planos
- Documentación clasificada y comunicaciones diplomáticas
- Datos personales que la ley obliga a proteger durante décadas
- Claves de firma de raíz y de firma de código con validez muy larga
La regla para decidir la urgencia se conoce como teorema de Mosca: si el tiempo que tus datos deben seguir siendo secretos, más el tiempo que tardarás en migrar, supera el tiempo que falta para que exista el ordenador cuántico, ya llegas tarde. Por eso los sectores con datos de larga vida están migrando el intercambio de claves ahora, aunque las firmas puedan esperar un poco más (una firma solo hay que resistirla hasta que el documento deja de tener valor, no retroactivamente).
3. Los estándares NIST de 2024
Tras un concurso público de ocho años, el NIST publicó en agosto de 2024 los tres primeros estándares de criptografía post-cuántica. Se apoyan en problemas matemáticos (retículos, funciones hash) para los que no se conoce ataque cuántico eficiente.
| Estándar | Nombre del algoritmo | Para qué sirve | Se basa en |
|---|---|---|---|
| FIPS 203 | ML-KEM (antes CRYSTALS-Kyber) | Encapsulado de clave (sustituye a ECDH) | Retículos (module-LWE) |
| FIPS 204 | ML-DSA (antes CRYSTALS-Dilithium) | Firma digital de propósito general | Retículos |
| FIPS 205 | SLH-DSA (antes SPHINCS+) | Firma digital basada solo en hashes (respaldo conservador) | Funciones hash |
ML-KEM es el que más prisa tiene, porque protege el acuerdo de clave y ahí ataca «harvest now, decrypt later». Para firmas, ML-DSA será el caballo de batalla y SLH-DSA queda como opción ultraconservadora (más lenta y con firmas grandes, pero su seguridad depende solo de que los hashes resistan, algo en lo que hay mucha confianza). El NIST sigue estandarizando un cuarto algoritmo de acuerdo de clave (HQC) como alternativa con base matemática distinta.
Tamaños: el precio a pagar
Las claves y firmas post-cuánticas son más grandes. Una clave pública X25519 ocupa 32 bytes; una de ML-KEM-768, unos 1.184. Una firma Ed25519 son 64 bytes; una de ML-DSA-65, unos 3.300. Esto encarece los handshakes y obliga a revisar campos, buffers y certificados pensados para tamaños pequeños
4. Despliegue híbrido: ya está ocurriendo
La forma sensata de migrar no es sustituir de golpe, sino combinar: hacer el acuerdo de clave con el algoritmo clásico y con el post-cuántico a la vez, y derivar la clave de sesión de los dos. Así, la conexión solo se rompe si un atacante vence ambos. Si el algoritmo post-cuántico nuevo tuviera un fallo aún no descubierto, sigues protegido por X25519; y si aparece el ordenador cuántico, sigues protegido por ML-KEM.
| Dónde | Estado (2025-2026) |
|---|---|
| TLS 1.3 en navegadores | Chrome y Firefox activan por defecto el híbrido X25519MLKEM768 en el acuerdo de clave |
| Servidores y CDN | Cloudflare, Google y otros grandes ya lo negocian; OpenSSL 3.5 trae ML-KEM de serie |
| SSH | OpenSSH usa por defecto un intercambio híbrido (mlkem768x25519) desde 2024 |
| VPN | WireGuard vía preshared key como parche; soluciones IKEv2 con marcos híbridos en curso |
| Firmas y certificados (PKI web) | Todavía en pruebas; la migración de las CA será posterior y más lenta |
Es muy posible que tu navegador ya esté haciendo handshakes post-cuánticos con varios sitios sin que hayas tocado nada. El acuerdo de clave es la parte fácil de cambiar porque es efímera y no requiere una infraestructura de confianza nueva; las firmas y los certificados vendrán después.
5. Qué puede hacer hoy una organización normal
No hace falta un proyecto cuántico ni comprar nada exótico. Los pasos son de higiene y de planificación:
- Inventario criptográfico: dónde se usa criptografía asimétrica —TLS, VPN, SSH, firma de código, PKI interna, cifrado de backups, tokens— y con qué algoritmos y tamaños. Sin este mapa no se puede priorizar. Herramientas de «CBOM» (cryptography bill of materials) empiezan a existir para esto
- Clasificar por vida útil del dato: marca qué sistemas manejan información que debe seguir secreta más de 10 años. Esos son los primeros candidatos a acuerdo de clave híbrido
- Exigir agilidad criptográfica a los proveedores: que el software que compras permita cambiar de algoritmo por configuración, no por reescritura. Pregúntalo en las compras nuevas
- Mantener el software al día: gran parte de la migración llegará sola en actualizaciones de OpenSSL, navegadores, bibliotecas TLS y sistemas operativos. Un parque actualizado migra casi solo
- Subir ya lo simétrico a 256 bits donde no lo esté, y retirar RSA-1024/2048 antiguos a favor de 3072+ o curva elíptica mientras llega lo post-cuántico
- Seguir las guías oficiales: NIST, y en Europa ENISA y los centros nacionales (en España, el CCN), publican calendarios y recomendaciones que conviene incorporar al plan
Cuidado con el humo comercial
«Cifrado cuántico» (QKD, distribución cuántica de claves) es una tecnología distinta, cara, que necesita fibra dedicada o enlaces ópticos y que resuelve un problema muy concreto; no es lo que necesita el 99 % de las organizaciones. Lo que hay que desplegar es criptografía post-cuántica —software, algoritmos del NIST— sobre la infraestructura que ya tienes. Desconfía de quien te venda hardware cuántico como solución general
Referencias
NIST Post-Quantum Cryptography (csrc.nist.gov/projects/post-quantum-cryptography) — FIPS 203, 204, 205 · NIST SP 1800-38 — guía práctica de migración a criptografía post-cuántica · ENISA y CCN-CERT — recomendaciones y calendarios para Europa y España · Cloudflare Research y el blog de Google sobre el despliegue de X25519MLKEM768 · Nuestros artículos sobre cifrado simétrico y asimétrico, TLS y PKI, y gestión de claves
Conclusión
La criptografía post-cuántica no es el fin del cifrado: es el recambio, ya estandarizado, de una pieza concreta —el intercambio de claves y las firmas de clave pública—. El cifrado simétrico y los hashes que protegen el volumen de los datos aguantan con ajustes menores. La urgencia real viene de «harvest now, decrypt later»: quien tenga datos que deban seguir secretos durante una década debería migrar el acuerdo de clave a un esquema híbrido ahora.
Para la mayoría de organizaciones el trabajo de este año no es criptográfico, es de inventario: saber dónde se usa criptografía asimétrica, qué datos tienen vida larga, y exigir agilidad criptográfica en las compras. El resto llegará en las actualizaciones de navegadores, OpenSSH y bibliotecas TLS —algunas ya están haciendo handshakes post-cuánticos sin que lo notes—.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)