Criptografía poscuántica: qué es y qué cambia con el NIST

La criptografía poscuántica es un grupo de algoritmos nuevos de llave pública que siguen siendo seguros aunque exista un computador cuántico grande. Le toca a cualquier empresa que use TLS, VPN, firma de código o certificados digitales, es decir, a casi todas. En corto: el NIST de Estados Unidos publicó tres estándares el 13 de agosto de 2024 (FIPS 203 para acordar llaves, FIPS 204 y FIPS 205 para firmar), tu navegador probablemente ya usa el primero y los algoritmos que reemplazan tienen fecha de retiro entre 2030 y 2035.

En América Latina el tema ya llegó a la agenda. El 22 de septiembre de 2026 la Asociación de Internet MX creó el Consejo Consultivo Quantum Safe México para emitir recomendaciones sobre criptografía, identidad digital y firma electrónica. Lo que sigue explica qué cambia y dónde está el trabajo para una empresa en Colombia, México, Chile o cualquier otro país de la región.

¿Qué es la criptografía poscuántica, en palabras simples?

Es criptografía de software común y corriente, basada en problemas matemáticos que nadie sabe resolver de forma eficiente, ni con computadores clásicos ni con cuánticos. Corre en los equipos que ya tienes. No necesita hardware cuántico.

El nombre confunde. “Poscuántica” (también la verás escrita “postcuántica” o “post-cuántica”) habla de la amenaza que debe resistir, no de la tecnología que usa. Tampoco es lo mismo que la distribución cuántica de llaves (QKD), que usa fotones y enlaces ópticos dedicados. La QKD tiene usos puntuales en telecomunicaciones y defensa. La criptografía poscuántica es lo que va a adoptar casi todo el mundo, porque entra en los mismos protocolos que usas hoy: TLS, SSH, IPsec y certificados X.509.

Cumple las dos tareas de la criptografía de llave pública. Una es el establecimiento de llaves: dos máquinas que nunca se han visto acuerdan una llave secreta a través de una red abierta. La otra es la firma digital: demostrar que un mensaje, una actualización de software o un certificado viene de quien dice venir. La factura electrónica y la firma electrónica que usan millones de empresas en América Latina dependen de certificados de llave pública, así que este cambio también les llega.

¿Por qué una computadora cuántica rompe RSA y no AES?

Un computador cuántico (computadora en México, ordenador en España) grande y con corrección de errores podría ejecutar el algoritmo de Shor, que factoriza números enormes y calcula logaritmos discretos de forma eficiente. RSA, Diffie-Hellman y la criptografía de curva elíptica dependen justo de que eso sea difícil. El cifrado simétrico, como AES, y las funciones hash, como SHA-256, enfrentan una ventaja cuántica mucho menor.

El borrador NIST IR 8547, de noviembre de 2024, dice que todas las primitivas simétricas aprobadas con al menos 128 bits de seguridad clásica cumplen, según lo que se sabe, al menos la primera de sus cinco categorías de seguridad poscuántica. AES-256 queda en la más alta. El problema está concentrado en la llave pública, que es la parte que reparte llaves y prueba identidades. El cifrado masivo de tus datos con AES se puede quedar como está.

Esto cambia la conversación de presupuesto. No hay que volver a cifrar todas las bases de datos. Hay que cambiar cómo se intercambian las llaves y cómo se firma, y eso toca pocas líneas de código pero muchos sistemas y muchos proveedores.

¿Qué definen FIPS 203, FIPS 204 y FIPS 205?

FIPS 203 estandariza ML-KEM, para establecer llaves. FIPS 204 estandariza ML-DSA y FIPS 205 estandariza SLH-DSA, los dos para firmas digitales. Salen de tres algoritmos que ganaron el concurso público del NIST: CRYSTALS-Kyber, CRYSTALS-Dilithium y SPHINCS+.

Los tamaños salen de las tablas de cada documento FIPS. Como referencia, una llave pública X25519 ocupa 32 bytes y una firma Ed25519 ocupa 64. Las llaves y firmas poscuánticas son decenas o cientos de veces más grandes, y ese salto de tamaño genera más problemas de integración que las matemáticas.

ML-KEM: el que más vas a ver

Un mecanismo de encapsulamiento de llaves (KEM) funciona así: el servidor publica una llave pública, el cliente la usa para envolver un secreto aleatorio y solo el servidor lo puede desenvolver. Los dos terminan con el mismo secreto de 32 bytes, que luego alimenta a AES durante la sesión. ML-KEM tiene tres tamaños (512, 768 y 1024). Los navegadores y SSH escogieron ML-KEM-768.

ML-DSA y SLH-DSA: dos estilos de firma

ML-DSA es la firma de uso general: bastante rápida, con firmas de entre 2,4 y 4,6 KB según los parámetros. SLH-DSA es más lenta y sus firmas son más grandes, pero su seguridad depende solo de funciones hash, que la criptografía estudia desde hace décadas. Por eso encaja en lo que se firma pocas veces y se verifica durante años, como el firmware de un equipo o un certificado raíz.

¿Y Falcon y HQC?

Vienen dos algoritmos más, y ninguno es excusa para esperar. FN-DSA, basado en Falcon, es un esquema de firma con firmas más pequeñas que ML-DSA; la página de estandarización del NIST lo lista como FIPS 206, todavía en desarrollo. HQC, un algoritmo de establecimiento de llaves basado en códigos correctores de errores, fue seleccionado el 11 de marzo de 2025.

HQC es un seguro. ML-KEM y ML-DSA se apoyan en problemas de retículos, y si alguien encontrara una debilidad ahí, el NIST quiere un respaldo con otra base matemática. Al anunciarlo, el NIST dijo que esperaba un borrador en cerca de un año y el estándar final en 2027. Dustin Moody, líder del proyecto poscuántico del NIST, fue claro sobre las prioridades: las organizaciones deben seguir migrando a los estándares finalizados en 2024.

¿Qué es un intercambio de llaves híbrido y ya lo estás usando?

Un intercambio híbrido ejecuta en paralelo un algoritmo clásico (normalmente X25519) y ML-KEM, y combina ambos resultados en la llave de la sesión. La conexión sigue segura mientras uno de los dos resista. Lo más probable es que lo estés usando mientras lees esto.

Los clientes más usados ya lo traen. Chrome 131, de noviembre de 2024, cambió el Kyber preliminar por el híbrido ML-KEM768 con X25519. OpenSSH 10.0 (abril de 2025) dejó mlkem768x25519-sha256 como intercambio por defecto, y OpenSSH 10.1 avisa cuando una conexión cae a un esquema que no es poscuántico. iOS 26, iPadOS 26, macOS Tahoe 26 y visionOS 26 ofrecen el grupo híbrido X25519MLKEM768 en TLS 1.3 por defecto. Y Cloudflare informó el 28 de octubre de 2025 que la mayoría del tráfico humano hacia su red ya usaba cifrado poscuántico.

La trampa es que eso suele cubrir el tramo entre el celular o el computador del usuario y el borde de la CDN o de la nube. Detrás quedan balanceadores, APIs internas, VPN, enlaces a bases de datos, módulos de seguridad de hardware (HSM) y las conexiones con aliados, pasarelas de pago y bancos corresponsales. Todo eso lo tienes que actualizar tú, y la mayor parte sigue negociando llaves con algoritmos clásicos.

Las firmas van más atrás. Los certificados de los sitios web siguen siendo RSA o ECDSA casi en todas partes, porque los certificados poscuánticos son grandes y el ecosistema todavía no ha definido cómo usarlos. Por ahora ese retraso es tolerable: para falsificar una firma hace falta el computador cuántico en el momento del ataque, mientras que un intercambio de llaves grabado hoy se puede romper años después. Esa es la amenaza de cosechar ahora, descifrar después.

¿Cuándo se retiran RSA y las curvas elípticas?

El borrador NIST IR 8547 propone declarar obsoletos los algoritmos de llave pública vulnerables con 112 bits de seguridad después de 2030, y prohibir RSA, ECDSA, ECDH y los demás después de 2035. Sigue siendo un borrador, pero los gobiernos ya tratan esas fechas como reales.

En Estados Unidos, la Orden Ejecutiva 14412 (firmada el 22 de junio de 2026) y el memorando M-26-15 de la OMB convirtieron esos años en obligaciones para los sistemas federales. La Unión Europea y el Reino Unido tienen calendarios propios con hitos entre 2028 y 2035. Una empresa latinoamericana que vende a gobiernos, bancos o multinacionales de esos mercados recibe esos plazos por contrato o en los cuestionarios de proveedores, aunque su propio regulador no haya dicho nada. Los detallamos en el artículo sobre plazos de la migración poscuántica.

¿Toca reescribir el software?

En general, no. En la mayoría de los sistemas se actualizan librerías, configuraciones de protocolo y productos de proveedores, no la lógica de negocio. El dolor aparece en sitios concretos: código que deja fijo un algoritmo en vez de leerlo de la configuración; columnas, mensajes y campos de protocolo pensados para una firma RSA de 256 bytes que ahora deben guardar 3.309; datáfonos, medidores, tarjetas inteligentes y otros equipos embebidos con poca memoria y sin forma de actualizarse; HSM cuyo firmware todavía no soporta ML-KEM ni ML-DSA; e integraciones donde el aliado tiene que cambiar al mismo tiempo que tú.

La meta de ingeniería se llama criptoagilidad: poder cambiar un algoritmo modificando configuración y desplegando, no reescribiendo código. El equipo que construye esa capacidad una vez va a poder incorporar HQC, FN-DSA y lo que venga sin otro proyecto de varios años. En el glosario están definidos este y los demás términos del artículo.

¿Qué algoritmo conviene elegir?

En la mayoría de los casos los protocolos ya decidieron por ti: ML-KEM-768 híbrido con X25519 para el intercambio de llaves en TLS y SSH, y ML-DSA para las firmas nuevas cuando tu autoridad de certificación y tu hardware lo soporten. SLH-DSA sirve para raíces de confianza de larga vida y para firmar firmware, donde importa más la confianza en las matemáticas que el tamaño.

Elegir algoritmos es lo fácil. Lo difícil es saber dónde vive la criptografía de llave pública en tu infraestructura, qué sistemas protegen datos que deben seguir secretos por una década y qué proveedores te van a frenar. Por eso los planes de transición de Estados Unidos, el Reino Unido y la Unión Europea empiezan con un inventario criptográfico, y por eso los sectores con datos de larga vida, como la banca y las finanzas o el sector público, suelen sentir la presión antes que los demás.

Si quieres saber qué tan expuestos están tus sistemas antes de comprometer un programa completo, una evaluación de preparación cuántica te da ese mapa en pocas semanas. Cuando llegue el momento de planear y ejecutar el cambio, la migración a criptografía poscuántica arranca desde ese inventario y avanza por tus sistemas en orden de riesgo.