Migración a criptografía poscuántica

Si abriste esta página en Chrome, lo más probable es que la conexión ya haya usado un intercambio de llaves poscuántico. Google lo activó por defecto en la versión 131, en noviembre de 2024, y a finales de octubre de 2025 Cloudflare reportó que más de la mitad del tráfico HTTPS generado por personas en su red ya lo usaba. La internet pública se está moviendo sola.

Adentro de tu empresa la historia es otra. La VPN con la procesadora de pagos, los certificados de los datáfonos, las llaves con que firmas la app móvil o la factura electrónica (el CFDI en México, la de la DIAN en Colombia), el HSM donde vive la CA raíz: nada de eso cambia cuando Chrome se actualiza. La migración a criptografía poscuántica es el trabajo planeado de llevar esos sistemas a los nuevos estándares del NIST, en un orden que proteja primero los datos más sensibles.

¿Qué algoritmos reemplazan a RSA y a las curvas elípticas?

Los algoritmos que reemplazan a RSA y a las curvas elípticas son los estándares poscuánticos que el NIST publicó el 13 de agosto de 2024: ML-KEM (FIPS 203) para el intercambio de llaves, y ML-DSA (FIPS 204) y SLH-DSA (FIPS 205) para las firmas. FN-DSA y HQC vienen en camino.

En la mayoría de los sistemas vas a usar ML-KEM y ML-DSA. SLH-DSA depende solo de funciones hash, así que es una opción conservadora para raíces de confianza de larga vida, pero sus firmas van de unos 8 KB a unos 50 KB según el conjunto de parámetros. FN-DSA da firmas mucho más pequeñas que ML-DSA y lo tenemos en cuenta donde el tamaño del certificado es un problema real, pero no recomendamos montar producción sobre un borrador. HQC existe para que tengas un intercambio de llaves con matemática distinta si algún día aparece una debilidad en las retículas. Vale la pena dejarle espacio en el diseño; desplegarlo hoy, no.

¿Por dónde empezar una migración a criptografía poscuántica?

Una migración a criptografía poscuántica empieza por el inventario criptográfico, porque no puedes migrar lo que no has encontrado y casi ninguna empresa tiene una lista completa de dónde corre su criptografía de llave pública. Ese inventario, junto con la vida útil de los datos que protege cada sistema, define el orden de todo lo demás.

Cruzamos tres fuentes. Los escaneos de red muestran qué negocian tus servidores TLS y SSH. El análisis de código y dependencias muestra qué librerías llaman tus aplicaciones y con qué algoritmos. Las entrevistas y la revisión de configuraciones cubren lo que los escáneres no ven: llaves guardadas en HSM, certificados grabados en firmware, cifrado de bases de datos, transferencias de archivos con aliados y servicios administrados cuyo interior no conoces.

El resultado es un CBOM (cryptographic bill of materials), un inventario de materiales criptográficos parecido al SBOM de software. Por cada elemento registra algoritmo, tamaño de llave, librería, responsable, qué datos protege y cuánto tiempo deben seguir confidenciales. Ese último dato define el orden. Un token de sesión que vence en una hora puede esperar. Un expediente de crédito hipotecario o una historia clínica que debe seguir privada 20 años, no.

Si nunca has hecho algo parecido, la evaluación de preparación cuántica es un primer paso más liviano para dimensionar el problema.

Agilidad criptográfica: que el próximo cambio salga barato

El cambio de arquitectura que más rinde es que el siguiente cambio de algoritmo cueste poco. Eso es la agilidad criptográfica: las aplicaciones le piden “un intercambio de llaves” o “una firma” a una librería o servicio central, en vez de tener RSA-2048 escrito a mano en cuarenta lugares.

Importa porque los estándares poscuánticos son jóvenes. HQC y FN-DSA van a llegar más tarde y van a aparecer errores de implementación. Una organización que cambia un algoritmo desde la configuración resuelve esos eventos en semanas. Una que tiene que parchar cada aplicación se demora años, más o menos lo que costó retirar SHA-1.

En la práctica buscamos criptografía concentrada en pocas librerías internas, identificadores de algoritmo en la configuración y no en el código, emisión de certificados automatizada de punta a punta y una forma de saber qué algoritmo usa cada servicio en producción.

Primero el intercambio de llaves híbrido

El intercambio de llaves es donde pega el ataque de “cosechar ahora, descifrar después”, así que casi siempre es lo primero que movemos. La opción estándar en 2026 es X25519MLKEM768 sobre TLS 1.3, que combina el X25519 clásico con ML-KEM-768. Si cualquiera de los dos componentes resiste, la llave de sesión sigue secreta.

El soporte ya está en la mayoría de las plataformas. OpenSSL 3.5, publicada el 8 de abril de 2025, trae ML-KEM, ML-DSA y SLH-DSA y ofrece X25519MLKEM768 por defecto en TLS. El trabajo es sobre todo actualizar las librerías detrás de balanceadores, API gateways, service mesh y concentradores VPN, y revisar que firewalls viejos y equipos de inspección TLS no se rompan con un saludo TLS más grande.

Firmas, PKI y HSM: la parte lenta

Mover las firmas cuesta más que mover el intercambio de llaves. Lo firmado dura mucho (firmware, documentos, versiones de software), las cadenas de certificados crecen (una firma ML-DSA-65 pesa 3.309 bytes contra 64 de ECDSA P-256) y la PKI depende de HSM, autoridades certificadoras y software cliente que tienen que ponerse de acuerdo.

Una secuencia realista empieza por la PKI interna que tú controlas, como el mTLS entre servicios, la firma de código y la firma de documentos, y deja para después los certificados web públicos. Esos dependen de decisiones de los navegadores y del CA/Browser Forum que no están en tus manos, así que los seguimos de cerca en lugar de planear alrededor de una fecha.

Con los HSM la pregunta es si tus modelos actuales pueden correr ML-KEM y ML-DSA con una actualización de firmware, si ese firmware conserva la validación FIPS 140-3 y si toca comprar hardware nuevo. Esa respuesta suele pesar en el presupuesto más que cualquier otra cosa.

Qué preguntarle a cada proveedor

Buena parte de tu criptografía corre dentro de productos que compras. A cada proveedor crítico le mandamos por escrito unas preguntas cortas y hacemos seguimiento:

• ¿Qué algoritmos poscuánticos del NIST soporta hoy el producto y desde qué versión?
• ¿Soporta intercambio de llaves híbrido (X25519MLKEM768) en TLS? ¿Viene activado por defecto?
• ¿El algoritmo se cambia por configuración o requiere una versión nueva?
• ¿Cuál es la hoja de ruta, con fechas, para certificados y firmas ML-DSA?
• ¿La implementación poscuántica va a tener validación FIPS 140-3, y cuándo?
• ¿Qué se rompe si el otro extremo de la conexión no soporta algoritmos poscuánticos?

Una respuesta vaga (“somos quantum-ready”) también es información: te dice dónde presionar o buscar alternativas.

¿Cómo se mide el impacto en rendimiento?

El impacto en rendimiento de la criptografía poscuántica se mide en tu entorno y con tus cargas reales, porque ML-KEM casi nunca es el cuello de botella. Sus operaciones son rápidas. Lo que crece son los bytes: saludos TLS más grandes, certificados más pesados y mensajes firmados más largos, que pesan sobre todo en redes lentas y dispositivos limitados.

Las pruebas típicas miden la latencia del saludo TLS a través de tus balanceadores, el rendimiento de los API gateways con más tráfico, el tamaño de la cadena de certificados en apps móviles con redes lentas y el uso de memoria y tiempo en dispositivos limitados como datáfonos o controladores industriales. Los protocolos con campos de tamaño fijo, en especial algunos formatos de IoT y de tarjetas inteligentes, son donde las firmas poscuánticas dan problemas de verdad.

¿Cuánto tarda una migración a criptografía poscuántica?

Una migración a criptografía poscuántica suele medirse en años en una empresa mediana o grande. El descubrimiento y el diseño ocupan unas ocho semanas. El piloto y el despliegue por olas dependen de tu tamaño y de tus proveedores, y los estimamos con el inventario hecho. Las fechas del NIST, 2030 y 2035, marcan el límite.

1. Descubrimiento (semanas 1 a 6). Inventario, CBOM, clasificación por vida útil de los datos y cuestionarios a proveedores.
2. Diseño (semanas 5 a 8). Arquitectura de agilidad criptográfica, backlog de migración y plan de pruebas, revisados con seguridad y arquitectura.
3. Piloto. Intercambio híbrido en un grupo limitado de servicios internos y externos, con mediciones y plan de reversa.
4. Despliegue por olas. Primero el intercambio de llaves en todo el parque, después las firmas y la PKI interna, y al final la cola larga de sistemas heredados y de proveedores.
5. Mantenimiento. El CBOM queda como un registro vivo, que se actualiza cuando el NIST publique la versión final de FIPS 206 y el estándar de HQC.

Los tiempos después del piloto dependen de tu tamaño y de tus proveedores; los estimamos con el inventario hecho, no antes. Bancos y aseguradoras suelen tener los datos de vida más larga y por eso backlogs más grandes; mira lo que escribimos sobre banca y finanzas y telecomunicaciones.

AndesQubit está abriendo proyectos por etapas. Si tu organización está planeando este trabajo, cuéntanos cómo son tus sistemas y te decimos cuándo podemos empezar y qué miraríamos primero.