El NIST publicó en agosto de 2024 los tres estándares definitivos de criptografía post-cuántica: FIPS 203 (ML-KEM, basado en CRYSTALS-Kyber), FIPS 204 (ML-DSA, basado en CRYSTALS-Dilithium) y FIPS 205 (SLH-DSA, basado en SPHINCS+). Medio año después, el titular ya no es noticia y toca convertirlo en plan. Este post recoge lo que he visto funcionar y lo que no en equipos que están empezando la transición, con la idea de ayudar a separar lo urgente de lo que puede esperar.
Lo primero que conviene asentar es el orden de magnitud. No hay aún un ordenador cuántico capaz de romper RSA-2048 o ECDSA P-256. Las estimaciones serias sobre cuándo lo habrá varían entre una década y nunca, y la honestidad profesional obliga a reconocer que no lo sabemos. Pero sí sabemos que adversarios con paciencia pueden interceptar hoy y descifrar mañana, lo que se conoce como “harvest now, decrypt later”. Para datos con valor a largo plazo, la transición no es opcional.
El inventario que casi nadie tiene
El primer paso es el más aburrido y el más ignorado: saber dónde está la criptografía en tu organización. No se trata solo de TLS en las webs públicas, que es lo obvio. Se trata de VPN entre oficinas, certificados de clientes en máquinas IoT, firmas en actualizaciones de firmware, JWT en APIs internas, cifrado en reposo de bases de datos, claves SSH de los servidores de administración, correo firmado S/MIME, integridad de logs de auditoría, y un largo etcétera.
En los equipos con los que he trabajado este año, el inventario rara vez se hace una vez. Lo sensato es abordarlo por capas. Primero las comunicaciones externas con terceros (donde las negociaciones dependen de algoritmos acordados). Luego la infraestructura interna (VPN, PKI propia). Después los datos en reposo con retención alta. Por último las integraciones con proveedores, que es donde más dolor hay porque no controlas el calendario del otro lado.
Una herramienta útil para empezar es pqc-iq de IBM, que escanea aplicaciones Java en busca de usos criptográficos, y los scripts que la comunidad ha publicado para analizar certificados X.509 y políticas de Kubernetes. No son perfectos, pero convierten un proyecto abstracto en una lista accionable.
Cripto-agilidad antes que cripto-correcta
El error más frecuente que veo en los primeros arranques es querer reemplazar algoritmos uno por uno. Se parchea una aplicación con ML-KEM y se deja el resto para después. Es tentador porque produce un tick en el informe, pero suele ser un error.
La conversación que rinde más es la de cripto-agilidad. En lugar de preguntar “¿qué algoritmo usamos?”, preguntar “¿cómo cambiamos el algoritmo sin reescribir la aplicación?”. Eso obliga a revisar abstracciones: dónde se instancia el proveedor criptográfico, si los formatos en disco y en red llevan identificadores de algoritmo, si la configuración está externalizada, si hay cadenas de compatibilidad para leer cifrado antiguo mientras se escribe con el nuevo.
Un sistema cripto-ágil bien diseñado hoy absorbe sin drama la primera transición a PQC, y absorberá también la segunda cuando los algoritmos actuales muestren debilidades (que las mostrarán: ML-KEM y ML-DSA son relativamente jóvenes, y la comunidad criptoanalista seguirá empujándolos). Un sistema cripto-rígido va a requerir reescrituras sucesivas.
Híbridos en lo externo, clásico en lo interno
La táctica que más ha cuajado en despliegues serios durante estos meses es usar algoritmos híbridos en los intercambios de clave de comunicaciones, y dejar el resto con criptografía clásica por ahora. Un híbrido combina ECDHE clásico con ML-KEM en la misma negociación, de modo que un atacante necesita romper los dos para tener éxito. Es conservador pero cuerdo: si ML-KEM resulta tener problemas inesperados, mantienes la seguridad clásica; si un ordenador cuántico aparece, mantienes la seguridad post-cuántica.
Cloudflare, Google y AWS ya soportan híbridos en sus extremos de TLS, y OpenSSH 9.9 estrenó la negociación híbrida en 2024 con el KEM sntrup761x25519. En 2025 muchos clientes lo usan sin saberlo. Para firmas digitales (ML-DSA o SLH-DSA), los híbridos son más complicados y la recomendación suele ser esperar un poco más antes de cambiar certificados de firma de código o firmas S/MIME, porque los tamaños son significativos y la infraestructura PKI no está lista.
Para cifrado simétrico en reposo, no hace falta urgencia: AES-256 sigue siendo seguro frente a adversarios cuánticos con el algoritmo de Grover, que reduce la seguridad efectiva a 128 bits (razonable). El cambio real está en cómo proteges las claves maestras, que es donde la criptografía asimétrica entra de nuevo.
Tamaños, latencias y presupuestos
Los estándares PQC no son drop-in. Las claves públicas de ML-KEM pesan entre 800 y 1568 bytes según el nivel de seguridad; las firmas de ML-DSA entre 2420 y 4595 bytes; las de SLH-DSA entre 7856 y 49856 bytes. Comparado con ECDSA P-256 (firma de 64 bytes) o Ed25519 (firma de 64 bytes), son órdenes de magnitud más.
Esto tiene implicaciones prácticas. Un certificado X.509 con ML-DSA crece de 1-2 KB a 4-6 KB. Una cadena completa TLS con tres certificados post-cuánticos se acerca a los 20 KB. En enlaces lentos (IoT celular, satélite) esto se nota. En enlaces normales no, pero el tráfico agregado de un CDN grande multiplicado por miles de millones de negociaciones diarias sí.
Las latencias por operación criptográfica son comparables o mejores que RSA en general, y ligeramente peores que las curvas elípticas modernas. Mi experiencia es que para servicios bien dimensionados no se nota, pero conviene medir. Los dispositivos con poca RAM (microcontroladores, tarjetas inteligentes) son el caso difícil, y para ellos SLH-DSA (basado en hashes) es una opción más cara en firma pero más barata en verificación y más resistente a criptoanálisis futuro.
El cronograma que tiene sentido
Mi sugerencia para un plan realista a principios de 2025 se parece a esto. En el primer trimestre, inventario criptográfico honesto. En el segundo, habilitar híbridos en TLS en todos los balanceadores y en el correo saliente cuando el partner lo soporte. En el segundo semestre, revisar la PKI interna y planificar una jerarquía post-cuántica para 2026-2027, sin prisa. En paralelo, adoptar cripto-agilidad como requisito en todo código nuevo, empezando por los proyectos donde puedes.
A medio plazo, los reguladores van a empujar. El BSI alemán tiene recomendaciones desde 2020, la ANSSI francesa se movió en 2022 y la CNSA 2.0 americana fijó objetivos para 2035. La Unión Europea, a través de ENISA, publicó una guía actualizada a finales de 2024 que varios gobiernos están adoptando. Si trabajas con sector público o infraestructuras críticas, los plazos llegarán antes.
Cómo pensar la decisión
Lo más valioso que he aprendido estos meses es que la transición post-cuántica es una excusa perfecta para hacer algo que ya necesitabas: ordenar la criptografía de tu organización. La mayoría de los equipos que se ponen hoy descubren durante el inventario que tenían claves RSA-1024 olvidadas, certificados con SHA-1, librerías desactualizadas o secretos hardcodeados. El PQC entra después; el orden previo es lo que realmente sube la seguridad.
La tentación es tratarlo como un proyecto de compliance, con una fecha y un tick. Y se puede hacer así, pero es caro y frágil. Tratarlo como una oportunidad para invertir en cripto-agilidad, higiene criptográfica y documentación es más rentable a medio plazo. El coste marginal de hacerlo bien es bajo cuando ya estás mirando el sistema.
Y si tu reacción ante todo esto es “lo dejamos para cuando aparezca un ordenador cuántico”, recuerda el harvest now, decrypt later. Los datos que encriptas hoy pueden descifrarse dentro de diez o veinte años si alguien los ha guardado. Para la mayoría de aplicaciones eso no importa; para actas jurídicas, historiales médicos, secretos comerciales o comunicaciones diplomáticas, importa mucho. Ahí la transición no es opcional, es cuestión de fechas.
