Criptografía Post-Cuántica: Urgencia Real en 2026
Los ataques Harvest Now, Decrypt Later ya están ocurriendo. Analizamos los estándares NIST FIPS 203/204/205 y los plazos federales de migración 2029-2031.
El problema que ya existe: Harvest Now, Decrypt Later
El ataque Harvest Now, Decrypt Later (HNDL) no es ciencia ficción. Actores de amenaza con acceso a infraestructura de interceptación pasiva —agencias de inteligencia estatales, en primer lugar— llevan años capturando y almacenando volúmenes masivos de tráfico TLS cifrado con RSA y ECDH. La apuesta estratégica es clara: cuando un ordenador cuántico suficientemente poderoso esté operativo, ese archivo de tráfico histórico se convierte en texto plano.
Lo que hace que HNDL sea especialmente peligroso es su carácter retroactivo. Un registro médico cifrado hoy con RSA-2048, cuyo período de confidencialidad requerido sea 20 años, ya tiene un perfil de riesgo cuántico. Una comunicación diplomática archivada hoy puede ser relevante en 2032. La criptografía post-cuántica (PQC) no es una preocupación del futuro: es una deuda técnica que se acumula en tiempo real.
Según el informe 2026 Quantum Threat Timeline del Instituto Global de Seguridad Cuántica, el 34% de las organizaciones Fortune 500 no ha iniciado ningún inventario criptográfico formal. Eso significa que no saben qué protegen, con qué algoritmo ni cuándo caduca esa protección.
Para comprender por qué RSA y ECDH son vulnerables, hay que partir del algoritmo de Shor. Publicado en 1994, demuestra que un ordenador cuántico puede factorizar enteros y resolver el problema del logaritmo discreto en tiempo polinómico. RSA-2048 —considerado seguro frente a computadores clásicos por más de 10^12 años— se rompe en cuestión de horas bajo Shor con aproximadamente 4096 qubits lógicos libres de error. ECDH, que basa su seguridad en el logaritmo discreto sobre curvas elípticas, es igualmente susceptible.
Los qubits lógicos son la clave: los sistemas actuales tienen decenas de miles de qubits físicos, pero la corrección de errores requiere entre 1000 y 10000 qubits físicos por qubit lógico. Aun así, la trayectoria de mejora es exponencial y el consenso técnico sitúa la amenaza operativa entre 2030 y 2035. Para infraestructura crítica con ciclos de vida de 10-15 años, migrar en 2033 ya sería demasiado tarde.
Para contexto adicional sobre cómo la inteligencia artificial acelera el vector de amenaza, ver nuestro análisis de agentes IA que comprometen credenciales escapando sandboxes.
NIST FIPS 203, 204 y 205: Los estándares que redefinen la criptografía federal
En agosto de 2024, el NIST publicó los primeros estándares de criptografía post-cuántica listos para producción. En 2026, son el punto de referencia obligatorio para cualquier organización que maneje datos gubernamentales estadounidenses o trabaje en su cadena de suministro.
FIPS 203 — ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)
Estandariza CRYSTALS-Kyber. Es el mecanismo de encapsulamiento de claves para establecer secretos compartidos en canales seguros. Viene en tres niveles de seguridad: ML-KEM-512 (Nivel 1, equivalente a AES-128), ML-KEM-768 (Nivel 3, equivalente a AES-192) y ML-KEM-1024 (Nivel 5, equivalente a AES-256). Para la mayoría de los sistemas federales, ML-KEM-768 es el mínimo aceptable.
FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm)
Basado en CRYSTALS-Dilithium. Reemplaza a ECDSA y RSA-PSS en firmas digitales. Tamaños de clave y firma mayores que ECC, pero con generación y verificación extremadamente rápidas. Sus parámetros ML-DSA-44, ML-DSA-65 y ML-DSA-87 corresponden a los niveles de seguridad 2, 3 y 5 respectivamente.
FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature)
Basado en SPHINCS+. No depende de ninguna estructura algebraica (retículos, isogenias, códigos). Su seguridad descansa únicamente en la resistencia de funciones hash como SHA-256 o SHAKE-256, lo que lo hace el más conservador de los tres. Sus firmas son grandes —entre 8 KB y 50 KB según parámetros— pero es ideal como firma de validación de firmware donde el tamaño no es un cuello de botella.
Adicionalmente, el NIST mantiene en evaluación un cuarto estándar, FALCON/FN-DSA (FIPS 206), optimizado para tamaños de firma más compactos y pensado para dispositivos IoT y firmware embebido.
Para un análisis complementario sobre cómo las políticas de privacidad se adaptan al entorno post-cuántico, ver Políticas de privacidad adaptadas a la IA y la protección legal en 2026.
Tabla comparativa: RSA-2048 vs ECDH P-256 vs ML-KEM-768
| Característica | RSA-2048 | ECDH P-256 | ML-KEM-768 |
|---|---|---|---|
| Base matemática | Factorización de enteros | Logaritmo discreto ECC | Retículos modulares (MLWE) |
| Seguridad clásica | ~112 bits | ~128 bits | ~184 bits |
| Resistencia cuántica | ❌ Rota con Shor | ❌ Rota con Shor | ✅ Segura (Nivel 3 NIST) |
| Clave pública | 256 bytes | 64 bytes | 1.184 bytes |
| Clave privada | 1.216 bytes | 32 bytes | 2.400 bytes |
| Ciphertext / Clave compartida | 256 bytes | 64 bytes | 1.088 bytes |
| Generación de claves (ops/s) | ~1.200 | ~14.000 | ~25.000 |
| Encapsulamiento (ops/s) | ~500 | ~11.000 | ~22.000 |
| Desencapsulamiento (ops/s) | ~100 | ~11.500 | ~25.000 |
| Estandarización federal | Legacy (deprecado 2030) | Legacy (deprecado 2030) | FIPS 203 (2024) |
Benchmarks medidos con OpenSSL 3.3 + liboqs en x86-64 (AMD EPYC 7763).
Implementación práctica: ML-KEM con OpenSSL y liboqs
El proyecto Open Quantum Safe (OQS) proporciona liboqs, una biblioteca C que implementa los algoritmos NIST PQC y se integra con OpenSSL 3.x mediante el proveedor oqs-provider. El siguiente ejemplo muestra un intercambio de claves ML-KEM-768 completo en C:
/*
* Ejemplo: Intercambio de claves ML-KEM-768
* Dependencias: liboqs >= 0.10.0, oqs-provider para OpenSSL 3.3
* Compilacion: gcc -o mlkem_demo mlkem_demo.c -loqs -lssl -lcrypto
*/
#include <stdio.h>
#include <string.h>
#include <oqs/oqs.h>
int main(void) {
OQS_KEM *kem = NULL;
uint8_t *public_key = NULL;
uint8_t *secret_key = NULL;
uint8_t *ciphertext = NULL;
uint8_t *shared_secret_enc = NULL;
uint8_t *shared_secret_dec = NULL;
int rc = OQS_ERROR;
/* Inicializar ML-KEM-768 (FIPS 203, Nivel 3) */
kem = OQS_KEM_new(OQS_KEM_alg_ml_kem_768);
if (kem == NULL) {
fprintf(stderr, "Error: ML-KEM-768 no disponible\n");
return 1;
}
public_key = malloc(kem->length_public_key);
secret_key = malloc(kem->length_secret_key);
ciphertext = malloc(kem->length_ciphertext);
shared_secret_enc = malloc(kem->length_shared_secret);
shared_secret_dec = malloc(kem->length_shared_secret);
/* Receptor: Generar par de claves */
rc = OQS_KEM_keypair(kem, public_key, secret_key);
printf("[Receptor] Par de claves generado.\n");
/* Emisor: Encapsular secreto compartido */
rc = OQS_KEM_encaps(kem, ciphertext, shared_secret_enc, public_key);
printf("[Emisor] Secreto encapsulado.\n");
/* Receptor: Desencapsular y recuperar secreto */
rc = OQS_KEM_decaps(kem, shared_secret_dec, ciphertext, secret_key);
printf("[Receptor] Secreto desencapsulado.\n\n");
if (memcmp(shared_secret_enc, shared_secret_dec,
kem->length_shared_secret) == 0) {
printf("Secreto compartido verificado. Intercambio exitoso.\n");
}
OQS_MEM_secure_free(secret_key, kem->length_secret_key);
OQS_MEM_secure_free(shared_secret_enc, kem->length_shared_secret);
OQS_MEM_secure_free(shared_secret_dec, kem->length_shared_secret);
free(public_key);
free(ciphertext);
OQS_KEM_free(kem);
return 0;
}
Para generar y verificar hashes de los materiales de clave, la herramienta Hash Generator de TecnoCrypter soporta SHA-3, que comparte la base matemática de SLH-DSA.
Los mandatos federales de EE. UU.: Plazos concretos para 2029-2031
La Directiva de Seguridad Nacional NSM-10 (mayo 2022) y las subsecuentes directrices OMB M-23-02 y CISA PQC Roadmap establecen un calendario de migración vinculante:
- 2025 (completado): Inventario completo de todos los sistemas criptográficos en uso. Identificación de activos de alta prioridad (sistemas de defensa, infraestructura crítica, datos clasificados).
- 2026 (en curso): Inicio de transición de sistemas de alta prioridad. Adopción de algoritmos híbridos (clásico + PQC) en nuevas implementaciones. Contratistas con contratos federales activos deben demostrar planes de migración documentados.
- 2028: Fase de transición completa para infraestructura de clave pública (PKI) federal. Autoridades de certificación deben emitir certificados con ML-DSA o SLH-DSA.
- 2029: Fecha límite para que todos los sistemas que manejen datos clasificados o Controlled Unclassified Information (CUI) estén completamente migrados a PQC. RSA y ECDH quedan prohibidos para nuevas negociaciones en estos contextos.
- 2030-2031: Deprecación formal de RSA-2048, RSA-3072, ECDH P-256 y P-384 en todos los contextos federales. Los contratistas que no cumplan quedan inhabilitados para contratos nuevos.
Estos plazos tienen un efecto cascada en la industria privada. Las empresas en sectores regulados que interactúan con el gobierno federal están adoptando los mismos calendarios.
Para entender el impacto de la computación cuántica sobre la infraestructura de IA de alto rendimiento, ver la alianza NVIDIA-SK Group y la memoria HBM4 para IA.
Crypto-Agility: La arquitectura de la transición
Crypto-agility es la capacidad de un sistema de cambiar algoritmos criptográficos sin rediseño estructural. Es el principio arquitectónico que se convierte en requisito de cumplimiento.
Una arquitectura crypto-agile implica cuatro capas:
Capa de abstracción criptográfica: Ningún código de aplicación llama directamente a
RSA_encrypt()oEC_KEY_new(). Toda la criptografía pasa por una interfaz unificada donde el algoritmo es un parámetro de configuración, no una constante compilada.Metadatos de versión en todos los objetos cifrados: Cada blob cifrado lleva un prefijo que identifica el algoritmo usado, permitiendo migración incremental sin romper datos históricos.
Inventario criptográfico automatizado: Herramientas como
cryptoscan(CISA) ocbom-tool(IBM) generan un Cryptographic Bill of Materials (CBOM) en cada ciclo CI/CD.Soporte híbrido durante la transición: Los estándares IETF permiten combinar ECDH con ML-KEM en un mismo handshake TLS 1.3. Google Chrome ya negocia X25519MLKEM768 por defecto desde la versión 124.
Para explorar cómo proteger tus tokens JWT durante la transición, la herramienta JWT Decoder de TecnoCrypter permite inspeccionar los campos alg y enc en tokens existentes.
Para comprender el papel de la IA en la detección de vulnerabilidades criptográficas, ver IA y ciberseguridad: capacitación organizacional para uso seguro.
El camino práctico para organizaciones en 2026
La migración post-cuántica no es un proyecto de un trimestre. Es un programa multi-año. El punto de partida es siempre el mismo: saber qué se tiene.
Un inventario criptográfico inicial debe responder a estas preguntas para cada sistema en producción: ¿qué algoritmo se usa para autenticación? ¿Para confidencialidad en tránsito? ¿Para confidencialidad en reposo? ¿Para integridad de software? ¿Cuál es el período de confidencialidad requerido?
Los sistemas con datos de larga duración —registros médicos, propiedad intelectual, documentos legales— son prioridad inmediata. Si el dato debe mantenerse confidencial durante más años de los que faltan para que la amenaza cuántica sea operativa, la protección actual ya es insuficiente.
Para generar materiales de clave seguros durante la transición, la herramienta Password Generator de TecnoCrypter genera entropía de alta calidad compatible con los requisitos de ML-KEM.
La urgencia de la criptografía post-cuántica no viene del futuro: viene de los archivos de tráfico interceptado que ya existen. Cada día de retraso es un día más de datos capturados con protección de fecha de caducidad conocida. Los estándares existen. Las bibliotecas son estables. Los plazos son inamovibles. Lo que resta es ejecutar.
