Criptografía poscuántica: lo que ya conviene desplegar

Criptografía poscuántica: lo que ya conviene desplegar

·5 min de lecturaSeguridad y Privacidad

La conversación sobre criptografía poscuántica cambió de tono en cuanto Google acortó su estimación del Q-Day de 2035 a 2029, según el reporte de CyberScoop sobre el nuevo calendario de Google. No se trata solo de una corrección técnica. Se parece mucho más a una fecha límite. Si hoy proteges credenciales bancarias, historiales clínicos o mensajes privados con RSA o ECC, el margen para migrar ya no luce cómodo.

La inquietud, además, no depende de que exista mañana una máquina cuántica útil. La lógica de “recolectar ahora y descifrar después” ya forma parte del riesgo. Estados y actores sofisticados pueden almacenar tráfico cifrado hoy con la expectativa de romperlo cuando el hardware madure. En un entorno donde 67% de las brechas ya comienzan con un acceso robado, el valor futuro de los datos robados importa casi tanto como el robo mismo.

El problema ya no es teórico

En agosto de 2024, NIST formalizó tres estándares centrales de criptografía poscuántica y dejó otros en la ruta, como explica su programa oficial de criptografía poscuántica. A primera vista, podría parecer que los seis algoritmos se reparten el mismo grado de madurez. No es así. Algunos ya son candidatos razonables para producción, otros funcionan como respaldo estratégico y uno, sencillamente, no llegó.

La diferencia es más importante de lo que parece. En seguridad, un algoritmo no vale solo por la solidez matemática de su diseño. También cuenta si cabe en infraestructura real, si no dispara la latencia, si no consume demasiada energía y si puede implementarse sin abrir nuevas fallas. Dicho de otro modo: la mejor opción no siempre es la más elegante, sino la que una organización puede adoptar sin convertir la transición en otro riesgo.

El candidato que quedó fuera del mapa

BIKE es el último de la fila. No ganó la competencia de NIST y perdió la plaza de respaldo frente a HQC. Su ventaja relativa estaba en ciertos escenarios de memoria, pero a niveles altos de seguridad el costo de latencia y energía terminó jugando en su contra.

Eso tiene una consecuencia práctica bastante simple. No habrá un estándar FIPS para BIKE. Por eso, si un proveedor lo presenta como señal de modernidad, conviene leerlo al revés: más que visión, puede revelar una apuesta fuera de la trayectoria principal del sector. En criptografía, insistir con un aspirante descartado rara vez es una señal tranquilizadora.

El respaldo matemático que todavía no está listo para todos

HQC, en cambio, sí conserva una función estratégica. Fue elegido como alternativa basada en códigos, distinta de la familia de algoritmos de retículos. La lógica de fondo es sensata: si algún día los esquemas basados en retículos pierden confianza, conviene tener una segunda base matemática lista.

Sin embargo, una póliza de seguro no siempre es una herramienta de uso diario. HQC sigue cargando con demandas altas de memoria y con una huella térmica que complica su despliegue en dispositivos limitados. En servidores puede ser aceptable. En sensores, móviles o hardware de borde, todavía plantea dudas. Por eso se parece más a un respaldo prudente que a una primera decisión de implementación.

Firmas digitales: seguridad máxima o compacidad con condiciones

Entre los esquemas de firma, SLH-DSA y FN-DSA ilustran dos filosofías distintas. SLH-DSA, derivado de SPHINCS+, se apoya por completo en funciones hash. Mientras esa base se mantenga sólida, ofrece una forma de confianza especialmente atractiva para archivos que deben verificarse durante décadas, como registros legales, archivos públicos o bitácoras de infraestructura crítica.

La contracara es el rendimiento. Sus firmas superan los 7.800 bytes, frente a unos 3.300 bytes de ML-DSA, y firmar resulta sensiblemente más lento. Eso vuelve poco realista su uso en tareas como TLS, donde cada byte y cada milisegundo cuentan.

FN-DSA, derivado de FALCON, propone casi lo contrario: firmas y claves más compactas, algo valioso en redes con ancho de banda ajustado, certificados encadenados o dispositivos IoT. Esa compacidad también dialoga con cambios como la transición de contraseñas a passkeys. El problema está en la implementación segura: requiere aritmética de punto flotante en tiempo constante durante la generación de claves, una combinación delicada desde el punto de vista de fugas laterales.

Lo que sí está listo para el mundo real

Si una organización necesita priorizar, hoy el núcleo práctico es bastante claro. ML-DSA, basado en CRYSTALS-Dilithium, ya funciona como el caballo de batalla para firma de código, autenticación y verificación documental. El análisis de rendimiento en TLS publicado en arXiv muestra velocidades de firma muy superiores a RSA-2048, con un costo operativo manejable.

Por encima de todos aparece ML-KEM, derivado de CRYSTALS-Kyber. Su fortaleza no es solo técnica, sino de adopción. Google lo activó en Chrome y Cloudflare afirma que 65% del tráfico humano que pasa por su red ya usa encapsulación de claves poscuántica. Cuando NIST plantea que la industria debe integrarlo “de inmediato”, el mensaje deja poco espacio para la ambigüedad.

La migración cómoda ya se terminó

Para la mayoría de los casos de uso, el mapa empieza a ordenarse solo. ML-KEM resuelve el intercambio de claves. ML-DSA cubre la mayor parte de las firmas. SLH-DSA queda como seguro para horizontes largos. FN-DSA merece seguimiento, pero no precipitación. BIKE ya pertenece más al archivo de la competencia que al plan de despliegue.

NIST también anticipa que los algoritmos vulnerables al quantum serán retirados hacia 2035, con sistemas más expuestos migrando antes. Si a eso se suma la velocidad con la que los ciberataques apoyados en IA reducen el tiempo entre robo y explotación, la ventana se achica todavía más. El ordenador cuántico que romperá cierto cifrado quizá aún no exista. Para decidir una transición, eso ya no es un consuelo suficiente.

Fuentes y Referencias

  1. NIST Computer Security Resource Center
  2. CyberScoop / Google
  3. Cloudflare
  4. arXiv (Performance Analysis of PQC in TLS)

Conoce nuestros estándares editoriales

También te puede interesar: