La criptografía poscuántica ya se aplica fuera del laboratorio. La Unión Europea pidió a sus Estados miembros que empiecen la migración antes de que termine 2026, y el NIST propuso fechas para retirar RSA y las curvas elípticas. Faltan dos meses para el primer plazo y muchas organizaciones todavía no saben dónde usan cifrado. Aquí explicamos qué cambia con la criptografía poscuántica, por qué conviene empezar aunque aún no exista el ordenador cuántico capaz de romper RSA, y cuántos bytes añade a una conexión real. ## El riesgo se llama «guardar ahora, descifrar después» En 1994, el matemático Peter Shor publicó un algoritmo que, ejecutado en un ordenador cuántico lo bastante grande, factoriza números enteros y resuelve logaritmos discretos en tiempo polinómico (o sea, en un tiempo que crece de forma manejable con el tamaño del problema). Sobre esos dos problemas se apoyan RSA, Diffie-Hellman y la criptografía de curva elíptica, que protegen casi todo el tráfico HTTPS, las VPN y las firmas de software. Hoy ninguna máquina cuántica se acerca a ese tamaño. El problema es otro: un atacante puede grabar hoy tráfico cifrado y esperar. Si dentro de quince años tiene el hardware, descifra lo que guardó. Para un historial médico, un expediente judicial o un secreto industrial con vida larga, eso basta para que el riesgo sea real ahora mismo. Michele Mosca, investigador de la Universidad de Waterloo, lo resumió en una desigualdad que se usa mucho en las auditorías de seguridad: $$X + Y > Z$$ En palabras: X es el número de años que tus datos deben seguir siendo secretos, Y es lo que tardarás en migrar tus sistemas y Z es el tiempo que falta para que exista un ordenador cuántico capaz de romper el cifrado actual. Si la suma de los dos primeros supera al tercero, ya vas tarde. Un ejemplo: datos que deben protegerse 10 años y una migración de 7 años suman 17. Si el ordenador cuántico llega en 15, hay dos años de exposición. ## Qué estándares existen ya El Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST) abrió en 2016 un concurso público para elegir algoritmos resistentes a ataques cuánticos. El 13 de agosto de 2024 publicó los tres primeros estándares definitivos. - **FIPS 203 (ML-KEM)** deriva de CRYSTALS-Kyber y sirve para acordar claves de sesión. Se basa en retículos (estructuras geométricas de puntos en muchas dimensiones donde encontrar ciertos vectores cortos es muy difícil, incluso para un ordenador cuántico). - FIPS 204, llamado ML-DSA, viene de CRYSTALS-Dilithium y se usa para firmas digitales. - El tercero, FIPS 205 o SLH-DSA, se apoya solo en funciones hash. Es más lento y genera firmas grandes, pero sus supuestos de seguridad son muy conservadores. - Como respaldo, en marzo de 2025 el NIST eligió HQC, un mecanismo basado en códigos correctores de errores, por si algún día aparece una debilidad en los retículos. Falcon, otro esquema de firma, está en preparación con el nombre FN-DSA. ## Las fechas que ya tienen nombre ```timeline 1994 : Peter Shor publica su algoritmo de factorización cuántica 2016 : El NIST abre la convocatoria de algoritmos poscuánticos 2022 : OpenSSH 9.0 activa por defecto un intercambio híbrido poscuántico 2024 : El NIST publica FIPS 203, 204 y 205 (13 de agosto) 2025 : HQC elegido como respaldo (marzo) y hoja de ruta europea coordinada (junio) 2026 : Fin de año, plazo europeo para iniciar la transición 2030 : Sistemas europeos de alto riesgo migrados; el borrador NIST IR 8547 propone declarar obsoletos RSA y ECC de 112 bits 2035 : Retirada prevista de RSA y ECC en los sistemas federales de EE. UU. y meta europea de migración general ``` La línea de tiempo empieza en 1994 con el algoritmo de Shor y llega hasta 2035. Entre 2016 y 2025 están el concurso del NIST, la publicación de los estándares y la elección de HQC. Desde 2026 aparecen los plazos regulatorios: a finales de 2026 los Estados de la UE deben haber empezado la transición, en 2030 deben estar migrados los sistemas de alto riesgo y en 2035 se prevé abandonar RSA y las curvas elípticas en casi todos los casos. El calendario europeo sale de la hoja de ruta coordinada que el Grupo de Cooperación NIS, que reúne a las autoridades de ciberseguridad de los países de la UE con la Comisión Europea, publicó en junio de 2025. Pide que cada país tenga hacia finales de 2026 un primer inventario y un plan nacional, con prioridad para las infraestructuras críticas. Ojo con esto: diciembre de 2026 marca el arranque. Ningún sistema tiene que estar ya migrado en esa fecha. ## Lo que ya funciona sin que lo notes Una parte de la migración ya ocurrió en los navegadores. Google Chrome activó por defecto en su versión 124, en abril de 2024, un intercambio de claves híbrido que combina X25519 clásico con Kyber, y en la versión 131 lo cambió por el ML-KEM estandarizado. Firefox siguió el mismo camino. Si visitas un sitio servido por Cloudflare desde un navegador actualizado, lo más probable es que esa sesión ya use ML-KEM. En mensajería, Signal añadió el protocolo PQXDH en 2023 y Apple lanzó PQ3 para iMessage con iOS 17.4 en 2024. OpenSSH 10.0, publicado en abril de 2025, usa por defecto mlkem768x25519-sha256. Hay un patrón común: casi todos usan modo híbrido, que combina un algoritmo clásico y uno poscuántico. Si el nuevo resultara tener un fallo, el clásico sigue protegiendo la sesión. Es una forma barata de no apostar todo a un algoritmo con pocos años de escrutinio. ## El precio se paga en bytes Los algoritmos nuevos tienen un costo práctico: sus claves y firmas son mucho más grandes. ```plotly {"data":[{"type":"bar","x":["X25519 (clave pública)","ML-KEM-768 (clave de encapsulado)","ML-KEM-768 (texto cifrado)","ECDSA P-256 (firma)","RSA-2048 (firma)","ML-DSA-44 (clave pública)","ML-DSA-44 (firma)"],"y":[32,1184,1088,64,256,1312,2420],"text":["32","1184","1088","64","256","1312","2420"],"textposition":"outside"}],"layout":{"title":"Tamaño en bytes: algoritmos clásicos frente a poscuánticos","yaxis":{"title":"Bytes"},"xaxis":{"tickangle":-30}}} ``` El gráfico compara tamaños en bytes. La clave pública de X25519 ocupa 32 bytes y la de ML-KEM-768, 1.184, unas 37 veces más. El texto cifrado de ML-KEM-768 pesa 1.088 bytes. En firmas, ECDSA P-256 usa 64 bytes y RSA-2048 usa 256, mientras que una firma ML-DSA-44 ocupa 2.420 bytes y su clave pública, 1.312. Para el intercambio de claves, el costo se asume bien: unos 2,2 KB extra por conexión. Aun así, hubo sorpresas. Cuando Chrome activó el modo híbrido, el primer mensaje del navegador (el ClientHello) pasó a superar el tamaño de un paquete típico de unos 1.500 bytes, y algunos servidores y cortafuegos antiguos que no esperaban mensajes partidos empezaron a cortar conexiones. Con las firmas el problema es mayor. Una conexión HTTPS normal incluye varias firmas y claves públicas en la cadena de certificados. Pasarlas todas a ML-DSA añade varios kilobytes a cada conexión nueva, algo que se nota en redes móviles lentas y en dispositivos IoT con poca memoria. Por eso el debate sobre certificados poscuánticos va más lento que el del cifrado de sesión. ## Por dónde empezar si te toca a ti La parte difícil de la migración es organizativa. Las matemáticas ya están resueltas y estandarizadas. Este es un orden razonable para un equipo técnico: 1. Haz un inventario criptográfico. Algunos equipos lo llaman CBOM (Cryptographic Bill of Materials): una lista de qué algoritmos, librerías, certificados y claves usa cada sistema. Sin ese mapa, el resto es adivinar. 2. Clasifica los datos según cuánto tiempo deben seguir siendo secretos. Aquí entra la desigualdad de Mosca: lo que debe protegerse más de diez años va primero. 3. Para el tráfico en tránsito, activar el modo híbrido en TLS y SSH suele ser el cambio más barato, porque OpenSSL 3.5, BoringSSL y OpenSSH ya lo traen. 4. Pregunta a tus proveedores por sus planes. Los módulos de seguridad hardware (HSM), las tarjetas inteligentes y los sistemas embebidos tienen ciclos de renovación de años, y conviene saberlo hoy. 5. Diseña pensando en la agilidad criptográfica (poder cambiar de algoritmo con configuración en lugar de reescribir código). HQC existe justo por si algo falla, y conviene que un cambio así no exija otro proyecto de cinco años. El hardware cuántico aún no amenaza el cifrado actual. El riesgo inmediato son los datos que alguien graba hoy y las aplicaciones con algoritmos programados de forma fija. Un inventario en noviembre de 2026 cuesta mucho menos que una migración de emergencia en 2031. ## Fuentes 1. «FIPS 203, FIPS 204 y FIPS 205: Post-Quantum Cryptography Standards». *National Institute of Standards and Technology (NIST)*, agosto de 2024. 2. «NIST IR 8547 (borrador inicial): Transition to Post-Quantum Cryptography Standards». *NIST*, noviembre de 2024. 3. «NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption». *NIST*, marzo de 2025. 4. «A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography». *Grupo de Cooperación NIS, Comisión Europea*, junio de 2025. 5. «OpenSSH 10.0 Release Notes». *Proyecto OpenBSD*, abril de 2025. 6. Shor, P. W. «Algorithms for quantum computation: discrete logarithms and factoring». *Actas del 35.º Simposio FOCS, IEEE*, 1994.
Comentarios
Sé el primero en comentar este artículo.
Deja un comentario