Por qué ML-KEM-1024 es el nuevo estándar para las comunicaciones seguras

Durante cincuenta años la criptografía asimétrica se ha sostenido sobre dos supuestos matemáticos: la dificultad de factorizar grandes enteros y la intratabilidad del problema del logaritmo discreto sobre curvas elípticas. RSA, Diffie-Hellman y ECDH han protegido cualquier cosa, desde los handshakes TLS hasta los enlaces militares de mando y control, con márgenes de seguridad que han crecido junto al tamaño de las claves.

El algoritmo de Shor, descrito por primera vez en 1994, quebró este paradigma en el plano teórico. Un computador cuántico tolerante a fallos de tamaño suficiente resolvería ambos problemas en tiempo polinómico, reduciendo RSA de 3072 bits y ECC P-256 a secretos trivialmente recuperables. Lo que ha mantenido en calma a la comunidad de seguridad ha sido la brecha de ingeniería entre el algoritmo teórico y la máquina práctica. Esa brecha se está reduciendo más rápido de lo que la mayoría de los defensores está dispuesta a admitir.

Los avances recientes en corrección de errores de qubits lógicos, en códigos de superficie y en compilación dinámica de circuitos han desplazado las estimaciones más creíbles del Q-Day hacia una ventana centrada en la próxima década. Para cualquier dato que deba permanecer confidencial más allá de esa ventana, la amenaza no es hipotética: ya está activa hoy en la forma de harvest-now decrypt-later, es decir, el almacenamiento actual de tráfico cifrado para descifrarlo cuando el hardware esté disponible [4][11].

ML-KEM es el acrónimo de Module-Lattice-Based Key-Encapsulation Mechanism. Es un esquema de encapsulamiento de clave, no una firma digital: su cometido es permitir que dos partes acuerden un secreto simétrico a través de un canal no confiable. El problema difícil subyacente es Module-LWE, una variante estructurada de Learning With Errors sobre anillos polinómicos, para la cual no se conoce actualmente ningún algoritmo cuántico subexponencial [5].

FIPS 203 especifica tres conjuntos de parámetros [1]. ML-KEM-512 apunta a la categoría de seguridad NIST 1 (aproximadamente AES-128). ML-KEM-768 apunta a la categoría 3 (AES-192). ML-KEM-1024 apunta a la categoría 5 (AES-256). Las diferencias residen en las dimensiones del retículo y en los parámetros de ruido, no en la estructura algorítmica. Las primitivas de encapsulamiento, decapsulamiento y generación de claves son idénticas en los tres casos.

El coste en términos de tamaño es moderado pero no despreciable. Una clave pública ML-KEM-1024 ocupa 1568 bytes, un ciphertext 1568 bytes, una clave secreta 3168 bytes. Frente a los 32 bytes de una clave pública X25519, se trata de un incremento de aproximadamente 49 veces. Para un handshake TLS esto significa algunos kilobytes adicionales por sesión. Para la mayoría de las aplicaciones es irrelevante. Para los enlaces de radio restringidos requiere atención de ingeniería [6].

La pregunta pragmática para cualquier arquitecto de sistemas es qué conjunto de parámetros adoptar. NIST acepta ML-KEM-768 como elección predeterminada para gran parte del uso federal. La NSA, mediante la directiva CNSA 2.0, impone ML-KEM-1024 para todos los National Security Systems y para cualquier dato clasificado Secret o superior [4]. La guía técnica TR-02102-1 del BSI alemán recomienda análogamente parámetros de categoría 5 para cualquier dato con horizonte de protección superior a diez años [9].

El argumento a favor de ML-KEM-1024 no es que ML-KEM-768 esté comprometido. Es que el margen de seguridad frente a futuros avances del criptoanálisis es notablemente más amplio. El criptoanálisis sobre retículos es un campo activo y varios trabajos recientes han refinado los modelos de coste de la familia de algoritmos de reducción BKZ. Cada refinamiento ha erosionado en unos pocos bits el nivel de seguridad conjeturado para ML-KEM-768. Ninguno ha mermado, en cambio, el margen de ML-KEM-1024.

Para las comunicaciones soberanas, las aplicaciones militares y los secretos industriales de larga duración, el caso es nítido. La diferencia de rendimiento entre categoría 3 y categoría 5 es del orden del 30-40% en ciclos de CPU, lo que para un intercambio de clave que ocurre una vez por sesión es operativamente invisible. La diferencia de ancho de banda es análoga. No existe ninguna razón defendible para elegir el parámetro más pequeño cuando se protege un dato con requisito de confidencialidad de varias décadas.

Todas las guías creíbles de despliegue, desde NIST SP 800-227 [10] hasta el trabajo de ETSI sobre mecanismos híbridos y el BSI alemán [9], recomiendan el establecimiento de clave híbrido durante la fase de transición. Un esquema híbrido combina una primitiva clásica (típicamente X25519 o ECDH P-384) con ML-KEM-1024, derivando la clave de sesión final a partir de los dos secretos compartidos mediante una KDF como HKDF-SHA384.

El razonamiento es prudencial. ML-KEM es joven. Ha sobrevivido a cuatro rondas de análisis público en el marco del proceso PQC de NIST [3], pero la comunidad de criptoanálisis ha tenido menos de una década para estudiar su versión definitiva. Un defecto sutil en la formulación reticular, en el muestreo del ruido o en la implementación podría en principio reducir su seguridad efectiva. La primitiva clásica es la red de seguridad: mientras al menos uno de los dos problemas subyacentes permanezca difícil, la clave de sesión permanece irrecuperable.

El coste del híbrido es una multiplicación escalar adicional y una llamada KDF, es decir, nada. El coste en complejidad es real y es donde la mayoría de los proyectos tropieza. Las entradas de la KDF deben ordenarse correctamente. La codificación de la longitud debe ser inequívoca. El fallo de un componente no debe filtrar información sobre el otro. Los borradores de la IETF sobre el híbrido, en particular draft-ietf-tls-hybrid-design [7], capturan el consenso sobre estos detalles.

ML-KEM es estructuralmente simple pero operativamente intolerante. La transformación de Fujisaki-Okamoto utilizada para obtener la seguridad IND-CCA2 se apoya en una comprobación de recifrado dentro del decapsulamiento. Las implementaciones que ramifican sobre el resultado de esa comprobación, o que liberan información temporal al respecto, se vuelven vulnerables a ataques con ciphertext elegido capaces de recuperar la clave secreta de largo plazo en pocos minutos. La implementación constant-time no es una recomendación, es un requisito.

La aritmética polinómica sobre el anillo Z_q[x]/(x^256 + 1) con q = 3329 se acelera típicamente mediante Number Theoretic Transform. Las implementaciones de la NTT que usan reducciones modulares no constant-time, o que presentan fugas de cache timing, han sido vulneradas en ataques side-channel publicados [6]. Las implementaciones hardware sobre FPGA y aceleradores dedicados han demostrado NTT plenamente constant-time, pero los despliegues puramente software sobre CPU general-purpose requieren codificación cuidadosa y verificación regular con herramientas como ctgrind o dudect.

La generación de números aleatorios para el muestreo del ruido es otro punto de ruptura. La implementación de referencia usa SHAKE-128 sembrado por un secreto de 32 bytes. Cualquier reducción de la entropía de esa semilla compromete el esquema entero. La única configuración de producción aceptable es entropía hardware procedente de un TRNG certificado, combinada con un DRBG conforme a NIST SP 800-90A.

El estudio de integración de ENISA sobre criptografía post-cuántica define la base europea para la migración [8]. Los Estados miembros lo están traduciendo ahora en mandatos nacionales: el BSI alemán ha alineado su catálogo criptográfico en torno a ML-KEM-1024 y ML-DSA-87 [9], y la ANSSI francesa ha emitido posiciones técnicas que exigen PQC híbrida para los productos cualificados.

Para los proveedores que venden a infraestructuras críticas europeas, defensa, telecomunicaciones o finanzas, la implicación operativa es concreta. Cualquier producto cuyo ciclo de vida certificado se extienda más allá de 2030 debe incluir ya un camino de migración PQC. Cualquier producto que entre en el mercado a partir de 2026, si declara dirigirse a casos de uso de confidencialidad prolongada, debe entregarse con la PQC activada por defecto. Los clientes preguntarán cada vez con mayor frecuencia no si usted soporta PQC, sino qué conjunto de parámetros entrega y cómo está construido el híbrido [7].

Si opera o construye sistemas que protegen datos con una ventana de confidencialidad superior a cinco años, ML-KEM-1024 en modo híbrido es la nueva línea de base. Adoptar ML-KEM-768 por defecto para ahorrar unos pocos kilobytes es una falsa economía: reconstruirá el mismo sistema dentro de tres años bajo presión regulatoria, a un coste significativamente más alto.

Primeros pasos prácticos: inventariar cada punto de su stack donde aparezcan RSA, ECDH o DH. Identificar cuáles de ellos tocan datos con un requisito de confidencialidad prolongada. Interpelar a sus proveedores de TLS, VPN y HSM sobre las hojas de ruta PQC y exigir ML-KEM-1024 híbrido con X25519. Para los protocolos propietarios, seguir los borradores de la IETF sobre el híbrido en lugar de ensamblar composiciones propias [7].

La transición no será barata, pero la alternativa es peor. El dato exfiltrado hoy y vulnerado en 2032 no es un riesgo hipotético: es la tesis operativa explícita de todas las agencias estatales de signals intelligence del planeta. ML-KEM-1024 es la respuesta prudente, defendible y alineada con el regulador a esa tesis. Es el nuevo estándar porque ya no existe ninguna razón creíble para elegir algo más débil [1][4][9].