Criptografía poscuántica: la hoja de ruta hacia la preparación cuántica

El criterio de planificación es el ordenador cuántico criptográficamente relevante (CRQC): suficientes qubits con corrección de errores y estabilidad de ejecución para ejecutar Shor contra longitudes de clave reales. Los sistemas actuales están a órdenes de magnitud de distancia. Por eso, la noticia de 2024 no fue una cifra récord, sino un cambio de tendencia: el chip Willow de Google mostró por primera vez, en condiciones reales, que la tasa de error desciende cuando crece el código de corrección de errores — el obstáculo central de escalabilidad es demostrablemente superable.

Por eso, lo decisivo no es la fecha del Q-Day, sino el período de confidencialidad de cada clase de datos: ¿durante cuánto tiempo sería perjudicial una divulgación? Todo aquello cuyo período de confidencialidad se extienda más allá del Q-Day —desconocido— ya está expuesto hoy, en cuanto atraviese una línea cifrada de forma clásica.

El valor del test está en su disciplina: x obliga a clasificar los datos con períodos de confidencialidad, y obliga a estimar honestamente la propia velocidad de cambio — valor de referencia en entornos consolidados: de tres a siete años, más en grandes corporaciones —, y z hace explícita la suposición sobre el Q-Day, en lugar de fijarla implícitamente en «algún momento». Realice el test por cada clase de datos, no una sola vez para toda la empresa: la dispersión entre las clases es precisamente la priorización que formaliza el capítulo 11.

Puede calcular el test de forma interactiva con la calculadora de Mosca en nuestra página de servicios de PQC.

Los procedimientos son rápidos, pero más voluminosos: las claves y las firmas crecen desde el rango de decenas de bytes hasta el de los kilobytes. ML-KEM-768 trabaja con una clave pública de 1.184 bytes y un texto cifrado de 1.088 bytes; ML-DSA-65 firma con 3.309 bytes, donde ECDSA P-256 necesita alrededor de 64; SLH-DSA-128s se sitúa en 7.856 bytes por firma. De ahí surgen los temas prácticos de la migración: paquetes de handshake, cadenas de certificados, almacenamiento en HSM, límites de MTU y campos de protocolo de longitud fija.

En TLS 1.3, el estándar de facto se llama X25519MLKEM768: el cliente y el servidor ejecutan X25519 y ML-KEM-768 en paralelo y fusionan ambos secretos en el esquema de claves. Para el caso genérico, el NIST estandariza la combinación en SP 800-227; el BSI designa en la TR-02102-1 (2026-01) CatKDF y KeyCombine como procedimientos recomendados. Importante para los auditores: lo híbrido no es un debilitamiento, sino la forma de operación de los años de transición expresamente recomendada por el BSI — a partir de 2032, el establecimiento de claves clásico deberá funcionar en todo caso solo de forma híbrida.

• Navegadores: Chrome, Edge y Firefox negocian X25519MLKEM768 por defecto.
• Red: más del 50 % del tráfico web humano en Cloudflare está cifrado de forma resistente a la computación cuántica (10/2025); desde 09/2026, «Automatic Key Exchange» eleva también los tramos hacia el origen.
• Mensajería: Signal (PQXDH, 2023) y Apple iMessage (PQ3, 2024) protegen de forma híbrida el establecimiento de sesión y la comunicación en curso, respectivamente.
• Bibliotecas: OpenSSL 3.5 LTS (04/2025) incorpora ML-KEM, ML-DSA y SLH-DSA de forma nativa; BouncyCastle y liboqs cubren los stacks de Java y de investigación.

Jurídicamente, la hoja de ruta es una recomendación — pero despliega su efecto de forma indirecta: define lo que los supervisores entenderán en el futuro por «estado de la técnica». Precisamente ese concepto es, en NIS2 y DORA, el rasero para la criptografía. Quien en 2028 tenga que explicar en una auditoría por qué los sistemas de alto riesgo aún cifran de forma clásica estará argumentando en contra de un consenso europeo documentado.

El plan de transición del NIST, IR 8547 (en borrador desde noviembre de 2024), clasifica los procedimientos con un nivel de seguridad de 112 bits —entre ellos RSA-2048 y ECDSA P-256— como «deprecated» a partir de 2030, y prevé «disallowed» para RSA y ECC en su conjunto a partir de 2035. Aún es un borrador, pero ya es referencia de la planificación de las agencias estadounidenses: los productos validados según FIPS y los servicios en la nube de EE. UU. irán retirando sus modos clásicos conforme a estas fechas — también para los clientes europeos.

Las señales son inequívocas: el Quantum Safe Financial Forum, en Europol, llamó en febrero de 2025 a entidades, proveedores y responsables políticos a elevar la migración a PQC a objetivo estratégico — cabe destacar: no mediante nueva regulación, sino de forma coordinada dentro del marco existente. En enero de 2026 le siguió, junto con FS-ISAC, una metodología conjunta de priorización que sopesa el riesgo cuántico frente al esfuerzo de migración. Ya en septiembre de 2024, el G7 Cyber Expert Group había pedido a los supervisores financieros que incorporaran los riesgos cuánticos en su planificación.

El resultado se consolida en una Cryptography Bill of Materials (CBOM) — un inventario legible por máquina de los componentes criptográficos, análogo a la SBOM para componentes de software y representable de forma estandarizada con CycloneDX. La diferencia con una lista de Excel: una CBOM es versionable, comparable (diff) y verificable en CI/CD — y responde como subproducto a las preguntas de los auditores (PCI 12.3.3, registro de certificados de DORA). Los hallazgos típicos son los mismos en todas partes: SHA-1 y 3DES en interfaces legacy, criptografía codificada de forma fija en el código fuente, proliferación descontrolada de certificados fuera de toda gobernanza de CA, almacenes de claves en la sombra en los despliegues — y una cadena de suministro que, de entrada, no puede decir qué criptografía contienen sus productos.

La arquitectura objetivo no «incorpora PQC», sino intercambiabilidad: algoritmos y longitudes de clave en políticas centrales en lugar de en el código de la aplicación, una capa de abstracción criptográfica, protocolos con margen para claves más grandes y nuevos identificadores, anclas de confianza móviles — y una gestión de claves centralizada con anclaje en HSM como columna vertebral, que de paso cumple el art. 7 del DORA-RTS. La prueba práctica de la agilidad se reduce a una sola pregunta: «¿Cuánto tiempo necesitaríamos para cambiar el establecimiento de claves en todos los servicios accesibles externamente?». Respuestas en días son señal de agilidad; respuestas en años, de necesidad de actuar.

El piloto (fase 4) no demuestra que la PQC funcione — de eso ya se han encargado miles de millones de conexiones de navegador —, sino que su operación puede con ello: ¿soporta la infraestructura los handshakes más grandes? ¿Reconocen la monitorización, las reglas del IDS y los parsers del SIEM los nuevos identificadores de algoritmo, en lugar de reportar los handshakes ML-KEM como anomalía? ¿Y funciona la vía de retorno documentada? El piloto concluye con una hoja de datos (deltas de latencia, tasas de error por clase de cliente, hallazgos de middleboxes, tasa de detección del SOC) — con lo que la decisión de implantación se convierte en un ejercicio de cálculo.

• Semana 1–2: obtener el mandato — propuesta de una página para la dirección con plazos, HNDL y coste del retraso; designar el comité de dirección.
• Semana 2–4: escanear la superficie externa — escaneo de TLS/certificados de todos los servicios accesibles externamente como la comprobación de realidad más rápida.
• Inmediato: eliminar los procedimientos obsoletos — desactivar SHA-1, 3DES, RSA-1024, o incluirlos con fecha en el registro de excepciones.
• Semana 3–6: definir los períodos de confidencialidad por clase de datos y calcular el test de Mosca por clase — la diapositiva más contundente para la dirección.
• Semana 4–10: encargar el inventario criptográfico como proyecto de discovery, consolidar el resultado como CBOM v1.
• En paralelo: preguntar de forma estructurada a los proveedores críticos por sus hojas de ruta PQC e incorporar la cláusula modelo en las adjudicaciones en curso.
• Semana 8–13: iniciar un piloto híbrido en un servicio real (X25519MLKEM768) con valores medidos.
• Semana 12–13: presentar el borrador de la hoja de ruta con el plan de olas, la senda presupuestaria, el conjunto de KPI y el ritmo de reporte.

Todas las plantillas —diapositiva para la dirección, cláusula modelo de compras, guía de objeciones— están incluidas en el whitepaper «Quantum Readiness para CISOs» (descarga arriba, en esta misma página).