Criptografía post-cuántica: lo que los desarrolladores deben hacer ahora

Los ordenadores cuánticos todavía no amenazan tu cifrado. Un ordenador cuántico capaz de romper RSA-2048 necesitaría millones de cúbits lógicos con corrección de errores — nosotros tenemos cientos de cúbits físicos ruidosos. Pero aquí está el problema: los adversarios podrían estar recopilando datos cifrados ahora mismo con la intención de descifrarlos más adelante, una vez que el hardware cuántico madure. Y migrar la infraestructura criptográfica lleva años.

Por eso los estándares de criptografía post-cuántica del NIST de 2024 son importantes para los desarrolladores hoy, no en 2035.

La amenaza real: el algoritmo de Shor

En 1994, Peter Shor demostró que un ordenador cuántico puede factorizar enteros grandes en tiempo polinómico O((log N)³). Esto rompe RSA, cuya seguridad se basa en que la factorización sea difícil. El mismo algoritmo — con modificaciones menores — rompe la criptografía de curva elíptica (ECC), que sustenta a ECDSA y ECDH.

Lo que se rompe:

• RSA (cifrado, firmas)
• ECDSA (firma — usado en TLS, SSH, firma de código, Bitcoin)
• ECDH (intercambio de claves — usado en TLS, Signal, WhatsApp, iMessage)
• Diffie-Hellman (intercambio de claves)

Lo que no se rompe:

• AES-256 (cifrado simétrico) — el algoritmo de Grover solo proporciona una aceleración cuadrática, reduciendo la fortaleza efectiva de la clave de 256 a 128 bits. Esto es manejable.
• SHA-256, SHA-3 (funciones hash) — lo mismo: Grover proporciona una aceleración menor, la seguridad se reduce a la mitad, sigue siendo lo bastante fuerte con los tamaños de clave actuales
• HMAC — seguro
• Argon2, bcrypt (hashing de contraseñas) — seguro

En resumen: la criptografía asimétrica necesita ser reemplazada; la criptografía simétrica necesita un aumento del tamaño de clave (AES-128 → AES-256).

Cosechar ahora, descifrar después

La amenaza no es "los ordenadores cuánticos romperán el cifrado el año que viene". La amenaza es:

1. Un adversario captura y almacena tu tráfico TLS cifrado hoy
2. En 2032–2040, ejecuta el algoritmo de Shor sobre él
3. Descifra todo retroactivamente

Este ataque — llamado "cosechar ahora, descifrar después" o HNDL — ya está ocurriendo. La NSA y otras agencias de inteligencia están casi con certeza almacenando grandes volúmenes de tráfico cifrado. El aviso de la NSA de 2022 advirtió explícitamente sobre esto.

Datos que necesitan protección hoy frente a HNDL:

• Secretos de estado, datos gubernamentales clasificados
• Datos personales de larga duración (historiales médicos, documentos de identidad)
• Datos financieros con largos requisitos regulatorios de retención
• Secretos comerciales y propiedad intelectual
• Bases de datos de contraseñas (aunque bcrypt/Argon2 son seguros)

Datos que no requieren preocupación inmediata:

• Tokens de sesión (de corta duración, sin valor dentro de 10 años)
• Mensajes de chat efímeros (a menos que seas un objetivo de alto valor)
• Información pública

Los estándares post-cuánticos del NIST (2024)

Tras una competición de 8 años, el NIST finalizó tres algoritmos de criptografía post-cuántica en agosto de 2024:

ML-KEM (CRYSTALS-Kyber) — Encapsulación de claves

• Reemplaza: el intercambio de claves RSA, ECDH
• Base de seguridad: el problema Module Learning With Errors (MLWE) — que se cree difícil tanto para ordenadores clásicos como cuánticos
• Rendimiento: rápido, claves pequeñas (~800 bytes para KEM-768), operaciones rápidas
• Usar para: intercambio de claves TLS, envoltura cifrada de claves, esquemas de cifrado híbrido

# Python example using pqcrypto library
from pqcrypto.kem.kyber768 import generate_keypair, encapsulate, decapsulate

public_key, secret_key = generate_keypair()

# Sender encapsulates a shared secret
ciphertext, shared_secret_sender = encapsulate(public_key)

# Receiver decapsulates
shared_secret_receiver = decapsulate(secret_key, ciphertext)

assert shared_secret_sender == shared_secret_receiver
# Now use shared_secret as AES key

ML-DSA (CRYSTALS-Dilithium) — Firmas digitales

• Reemplaza: ECDSA, RSA-PSS para firma
• Base de seguridad: problemas MLWE + MSIS
• Rendimiento: tamaños de clave moderados (~1,312 bytes de clave pública), firma rápida
• Usar para: firma de código, certificados TLS, firma de documentos, firmas JWT

from pqcrypto.sign.dilithium3 import generate_keypair, sign, verify

public_key, secret_key = generate_keypair()

message = b"Deploy to production"
signature = sign(message, secret_key)

# Verify
assert verify(message, signature, public_key)

SLH-DSA (SPHINCS+) — Firmas basadas en hash

• Reemplaza: ECDSA como respaldo conservador
• Base de seguridad: solo funciones hash — la opción más conservadora
• Rendimiento: firmas más grandes (~8–50 KB), firma más lenta
• Usar para: firma de alta garantía donde la reutilización de claves es una preocupación, firma de documentos a largo plazo

El NIST también estandarizó FALCON (FN-DSA) — un esquema de firma basado en retículos con firmas compactas, adecuado para entornos con recursos limitados como IoT.

Qué hacer ahora: un plan de acción por niveles

Nivel 1 — Hazlo hoy (bajo esfuerzo, alto impacto)

Audita tu inventario criptográfico. No puedes migrar lo que no has catalogado. Documenta:

• ¿Dónde usa TLS tu aplicación? (La mayoría de los frameworks lo gestionan)
• ¿Dónde generas o verificas firmas? (JWT, firma de código, firma de PDF)
• ¿Dónde usas intercambio de claves asimétrico? (claves AES envueltas con RSA, SSH)
• ¿Qué bibliotecas estás usando? (OpenSSL, BouncyCastle, AWS KMS, etc.)

Actualiza AES-128 a AES-256. Esto es de bajo riesgo e inmediato. AES-256 se reduce a 128 bits de seguridad frente a Grover — todavía más que seguro.

Habilita TLS 1.3 en todas partes. TLS 1.3 usa confidencialidad hacia adelante (forward secrecy) por defecto (ECDHE), lo que significa que las sesiones pasadas no pueden descifrarse aunque la clave a largo plazo se vea comprometida. Esto mitiga parcialmente HNDL para el tráfico TLS.

Nivel 2 — Planifica para los próximos 6–18 meses

Adopta el intercambio de claves híbrido en TLS. El grupo de trabajo de TLS ha estandarizado X25519Kyber768 — un esquema híbrido que usa tanto ECDH clásico como ML-KEM. Google Chrome, Cloudflare y AWS ya lo soportan. Esto protege contra HNDL manteniendo la seguridad clásica:

# Nginx with OpenSSL 3.x + oqs-provider (Open Quantum Safe)
ssl_ecdh_curve X25519Kyber768;  # hybrid classical + PQC

Reemplaza RSA/ECDSA en sistemas nuevos por ML-DSA. Para cualquier cosa desde cero — nuevos microservicios, nuevas implementaciones de JWT, nuevos despliegues de SSH — usa ML-DSA (Dilithium3 o Dilithium5) en lugar de ECDSA-256.

Actualiza tu pipeline de certificados TLS. La mayoría de las CA públicas aún no emiten certificados PQC, pero puedes usar ML-DSA hoy para certificados firmados internamente y certificados de service mesh.

Nivel 3 — Migración a largo plazo (1–5 años)

Migración completa de la PKI. Reemplaza tu jerarquía de certificados RSA/ECC por una infraestructura de CA basada en PQC. Esta es la parte más difícil — los módulos de seguridad hardware (HSM), la rotación automatizada de certificados y las cadenas de certificados necesitan actualizarse.

Hardware y dispositivos embebidos. Los dispositivos IoT y embebidos a menudo no pueden parchearse de forma remota y tienen ciclos de vida de más de 10 años. Audita cualquier dispositivo de este tipo que dependa de RSA o ECDSA para la autenticación.

Sistemas de gestión de claves. AWS KMS, Azure Key Vault, HashiCorp Vault — verifica sus hojas de ruta de PQC y sus cronogramas de migración.

Soporte de bibliotecas y frameworks

Resumen en una página

What breaks:    RSA, ECDSA, ECDH, classical DH
What's safe:    AES-256, SHA-256, SHA-3, bcrypt, Argon2
New standards:  ML-KEM (Kyber) for key exchange
                ML-DSA (Dilithium) for signatures
                SLH-DSA (SPHINCS+) for conservative signing

Do today:       Upgrade AES-128 → AES-256
                Enable TLS 1.3 (forward secrecy)
                Audit crypto inventory

Do soon:        Hybrid TLS key exchange (X25519Kyber768)
                ML-DSA for new signature systems

Do in 1-5 yrs:  Full PKI migration to PQC
                Firmware updates for IoT devices

La amenaza cuántica a la criptografía es real y el calendario es incierto — que es exactamente por lo que actuar ahora, antes de que los ordenadores cuánticos sean capaces, es la decisión correcta.

Lectura adicional: Glosario de computación cuántica — Algoritmo de Shor · Lo que los ordenadores cuánticos pueden hacer hoy