Criptografía poscuántica: qué migrar primero y qué exigir a los proveedores

La criptografía poscuántica reúne algoritmos diseñados para resistir ataques tanto de computadoras convencionales como de futuras computadoras cuánticas. Se la suele abreviar PQC, por post-quantum cryptography. Se ejecuta en equipos convencionales: una empresa no necesita una computadora cuántica para implementarla. Programa de criptografía poscuántica de NIST.

Las conexiones seguras, los certificados y las firmas digitales usan hoy algoritmos como RSA y los de curva elíptica. Una computadora cuántica suficientemente potente podría resolver los problemas matemáticos de los que depende su seguridad. Reemplazarlos exige actualizar aplicaciones, dispositivos y servicios que deben seguir funcionando entre sí. El director de seguridad de la información (CISO) tendrá que prever esas actualizaciones en las compras y renovaciones de contratos, especialmente cuando los equipos o los documentos deban durar muchos años. Programa de criptografía poscuántica de NIST.

Por qué Shor amenaza a RSA y qué cambia con los nuevos algoritmos

Una computadora cuántica necesita un algoritmo adecuado para resolver cada problema. El algoritmo de Shor permite factorizar números enteros y calcular logaritmos discretos en tiempo polinómico. La seguridad de RSA y de los esquemas de curva elíptica depende de la dificultad de esos problemas. Con una computadora cuántica suficientemente grande y tolerante a errores, Shor permitiría obtener claves privadas a partir de información pública. El procedimiento matemático ya existe; ejecutarlo contra claves de uso real exige una capacidad de hardware que todavía debe alcanzarse. Trabajo de Peter Shor.

Los algoritmos poscuánticos cambian el problema que debe resolver el atacante. ML-KEM y ML-DSA se apoyan en problemas de retículos, estructuras matemáticas de muchas dimensiones. SLH-DSA utiliza funciones hash para construir firmas. Para los problemas y parámetros en los que se basan estos estándares, no se conocen algoritmos cuánticos eficientes que permitan romperlos, como sí ocurre con Shor frente a la factorización y al logaritmo discreto. Explicación de NIST sobre criptografía poscuántica.

En ML-KEM, el atacante se enfrenta al problema de recuperar un secreto a partir de relaciones algebraicas a las que se agrega un pequeño error o “ruido”. Ese problema se conoce como Module Learning With Errors. Con los parámetros elegidos, ese ruido dificulta reconstruir el secreto incluso con los ataques cuánticos conocidos. Fundamento de ML-KEM en FIPS 203.

Grover es otro algoritmo cuántico que se considera al evaluar la seguridad: acelera búsquedas exhaustivas y afecta la elección de tamaños de claves y parámetros. Su efecto es diferente del de Shor. Las estimaciones se revisan cuando aparecen mejores ataques; las implementaciones deben permitir actualizar algoritmos y parámetros si esas revisiones lo requieren. Preguntas técnicas de NIST sobre seguridad poscuántica.

Qué publicó Google y por qué importa para la firma digital

En mayo de 2025, Craig Gidney, de Google Quantum AI, estimó que sería posible factorizar RSA-2048 con menos de un millón de qubits físicos ruidosos y menos de una semana de ejecución, bajo los supuestos de hardware y corrección de errores del estudio. La estimación de 2019 requería veinte millones de qubits y ocho horas. La mejora reduce el hardware requerido a cambio de más tiempo de ejecución. Es una estimación de un ataque futuro, no una clave RSA-2048 rota en un equipo actual. Estudio de Gidney.

El 31 de marzo de 2026, Google presentó otro trabajo sobre el logaritmo discreto en curvas elípticas de 256 bits. Estimó que, con una futura computadora cuántica superconductora y los supuestos del estudio, el ataque podría ejecutarse con menos de 500.000 qubits físicos, en una escala de minutos. El artículo apareció en PRX Quantum el 21 de agosto de 2026. Su análisis se centra en la curva secp256k1 utilizada en criptomonedas; esas cifras no deben trasladarse directamente a cualquier curva o certificado de firma. Anuncio de Google y publicación científica.

Otro grupo de investigadores publicó el preprint ECDSA.Fail, presentado el 9 de septiembre y revisado el 19. El trabajo describe optimizaciones de la suma de puntos, una operación utilizada por Shor. Sus autores advierten que las diferencias de interfaces y de medición limitan la comparación con Google. Mejorar esa operación no equivale a ejecutar un ataque completo contra una firma en producción. ECDSA.Fail, versión 2.

Si un atacante reconstruye la clave privada de un firmante, puede generar firmas nuevas que se verifiquen con la clave pública del titular. El ataque a esa clave no necesita romper SHA-256, la función hash que puede intervenir en el cálculo de la firma. Los trabajos citados analizan RSA o curvas elípticas; no demuestran una ruptura de SHA-256.

Al revisar un servicio de firma, compruebe qué algoritmo usa para firmar, qué certificados intervienen y qué evidencia conserva sobre la fecha del documento. Cambiar solamente el hash no resuelve una vulnerabilidad de RSA o ECDSA.

Qué revisar antes de renovar equipos y contratos

Un módulo de seguridad de hardware (HSM) comprado en 2026 puede seguir en servicio en 2033. Antes de comprarlo, conviene establecer por contrato cómo se actualizará su criptografía, quién lo hará y cuánto costará. Si el cambio requiere reemplazar el equipo, ese costo debería figurar en la evaluación de compra.

El 3 de septiembre de 2026, el grupo de trabajo de ciberseguridad del G7 publicó un llamado a iniciar la transición poscuántica. El documento recomienda comenzar la migración y reconoce la incertidumbre sobre cuándo habrá capacidad cuántica suficiente para atacar los sistemas actuales. Documento del G7 publicado por ANSSI.

El presupuesto debería distinguir equipos actualizables, equipos que habrá que reemplazar y servicios que dependen de una versión aún no entregada por el proveedor. La prioridad depende, entre otros factores, de cuánto tiempo deben protegerse los datos y de cuánto demorará cada cambio.

Qué está estandarizado y qué sigue en evaluación

NIST publicó en agosto de 2024 tres estándares que cubren dos operaciones diferentes:

ML-KEM permite obtener material secreto que un protocolo puede usar con criptografía simétrica para proteger una comunicación. No firma documentos. ML-DSA y SLH-DSA sirven para autenticidad e integridad; elegir uno de ellos tampoco cifra el contenido firmado. En el inventario, registre por separado los algoritmos de intercambio de claves y los de firma. FIPS 203, FIPS 204 y FIPS 205.

Al cierre de esta revisión, NIST sigue describiendo Falcon y HQC como algoritmos seleccionados cuyo proceso de estandarización está en curso. Pida al proveedor el estado de la especificación que implementa, sus parámetros y la versión utilizada. Estado del proyecto PQC de NIST.

La ficha de FIPS 204 incorporó el 31 de julio de 2026 una nota sobre erratas que se corregirán en una revisión futura. El soporte del producto debe contemplar cómo se distribuyen esas correcciones y cómo se comprueba que quedaron aplicadas. Ficha y erratas de FIPS 204.

A quiénes se aplican los plazos de migración

Los cronogramas de NIST, la Unión Europea y el Reino Unido tienen destinatarios y prioridades diferentes:

Fuentes de la tabla: NIST IR 8547, tablas 3 y 4, hoja de ruta europea, secciones 4 y 6 y cronograma del NCSC.

El borrador de NIST no establece una prohibición general de RSA en 2030. Sus tablas distinguen la operación criptográfica y el nivel de seguridad. Su ficha oficial permite comprobar ese estado.

La FAQ europea también precisa que el hito de 2030 corresponde a los casos de alto riesgo: pertenecer a infraestructura crítica no asigna automáticamente la misma prioridad a cada sistema. Los hitos corresponden al despliegue, por lo que los productos y estándares deben estar disponibles antes. Estas precisiones figuran en la FAQ del 15 de abril de 2026. FAQ, preguntas 4.1 y 7.3.

Una empresa argentina puede recibir estos plazos a través de contratos con proveedores o requisitos de clientes internacionales. Para cada sistema, identifique si existe una obligación aplicable, de qué documento surge y quién verificó su alcance.

Separar confidencialidad, autenticación y conservación

Un adversario puede capturar tráfico cifrado hoy y conservarlo para intentar descifrarlo años después. Si los datos deben seguir siendo confidenciales durante ese período, el riesgo afecta a las comunicaciones actuales. NIST lo contempla en su documento de transición. NIST IR 8547, sección 3.

Una conexión que transporta historias clínicas puede requerir prioridad sobre un servicio cuyos datos pierden valor rápidamente. Hay que revisar qué transmite, quién podría capturarlo y cuánto llevaría actualizar ambos extremos.

En un equipo que recibe firmware durante quince años, la clave usada para verificar las actualizaciones puede estar incorporada en fábrica. Antes de comprarlo, hay que averiguar si ese mecanismo admite cambios. Una limitación allí podría obligar a reemplazar el hardware.

Para los documentos firmados, el plazo relevante es el de conservación: durante cuánto tiempo habrá que demostrar su integridad y verificar las firmas. Actualizar las comunicaciones no modifica los contratos ya archivados. Su preservación requiere procedimientos y presupuesto propios.

Qué registrar en el inventario criptográfico

El inventario debe incluir, además de los certificados públicos, la criptografía usada por aplicaciones, bibliotecas, equipos y servicios contratados. El proyecto de migración del NCCoE estudia herramientas para localizar esos usos y priorizar su reemplazo. Proyecto de migración del NCCoE.

Para cada servicio, registraría:

• Servicio y responsable: quién puede aprobar y ejecutar el cambio.
• Función criptográfica: intercambio de claves, autenticación, firma de código, firma documental o protección de claves almacenadas.
• Implementación: algoritmo, parámetros, protocolo, biblioteca o firmware y versión.
• Dependencias: certificados, HSM, clientes, verificadores y proveedores que participan.
• Plazo de protección: vida útil del equipo, confidencialidad del dato o conservación de la evidencia.
• Cambio previsto: actualización, reemplazo, fecha comprometida, costo y prueba pendiente.

Una entrada como “aplicación de contratos: usa RSA” necesita más detalle. Puede referirse al certificado del servidor, a la firma del PDF o a la protección de otra clave. Identificar cada uso permite asignar el cambio al equipo correspondiente.

Si ya se detectó un uso de alto riesgo, puede comenzarse su migración mientras continúa el relevamiento. La FAQ europea contempla trabajar en inventario, planificación y migración en paralelo. FAQ, pregunta 4.2.

Probar tamaños, latencia y validadores

FIPS 204 especifica 2.420 bytes para una firma ML-DSA-44, 3.309 para ML-DSA-65 y 4.627 para ML-DSA-87. Son tamaños de la firma, sin contar certificados, estructuras del formato ni evidencias adicionales. FIPS 204, tabla 2.

Antes de cambiar un flujo documental, revisaría los espacios reservados para la firma, los límites de los mensajes, el almacenamiento y los validadores de los destinatarios. En una integración antigua puede existir una columna o un campo binario dimensionado para el algoritmo anterior. Las pruebas deben incluir el envío, la recepción y la verificación de la firma, además de su generación.

En un servicio de firma, mediría el tiempo de firma y validación, el consumo de recursos y la tasa de errores con los volúmenes reales del cliente. También probaría la apertura y verificación del documento en las herramientas del destinatario. El NCCoE estudia la interoperabilidad de implementaciones poscuánticas. Alcance de las pruebas del NCCoE.

Si es necesario volver a la versión anterior del servicio, los documentos emitidos durante la prueba deben seguir siendo legibles y verificables. Incluya ese caso en la prueba de reversión y conserve las evidencias necesarias para validarlos.

Qué pedir por escrito al proveedor

Antes de renovar un HSM o contratar un servicio de firma o identidad, pida por escrito:

1. Versión disponible. Algoritmos y parámetros soportados hoy, diferenciados de pruebas de laboratorio y desarrollos futuros. Fecha, versión y condiciones de soporte para cada entrega pendiente.
2. Compatibilidad. Protocolos, formatos, clientes y validadores probados. Restricciones de los entornos regulados o de las políticas de certificados aplicables.
3. Costo de transición. Qué entra en mantenimiento y qué requiere licencia, recertificación, recambio de equipo o trabajo profesional adicional.
4. Actualización y exportación. Procedimientos de actualización, recuperación y exportación de datos y evidencias. Dependencias que podrían impedir cambiar de proveedor.
5. Prueba de aceptación. Un caso reproducible en un entorno representativo, con criterios acordados antes de comprar.

Para un HSM, agregaría el número de validación, su estado y la política de seguridad de la versión ofrecida. FIPS 140-3 evalúa un módulo criptográfico; FIPS 203, 204 y 205 especifican algoritmos. La validación del módulo debe corresponder a la versión y a las funciones que se van a usar. Programa CMVP de NIST.

Pida una demostración del cambio de algoritmo: instalación, comprobación de la configuración activa y retiro de la anterior. Es parte de lo que se conoce como criptoagilidad. NIST trata esas dependencias técnicas y organizativas en CSWP 39, publicado en diciembre de 2025 y actualizado en junio de 2026. CSWP 39.

Mientras la versión compatible no esté entregada y probada, registre la migración como pendiente.

Qué hacer con las firmas que ya existen

Las firmas de los documentos archivados conservan el algoritmo con el que fueron emitidas. Para verificarlas a largo plazo se necesitan las evidencias de validación y una prueba de que el documento existía cuando los mecanismos utilizados aún eran seguros.

El RFC 4998, Evidence Record Syntax, describe registros de evidencia y renovación de sellos de archivo antes de que sus mecanismos pierdan seguridad. Distingue la renovación del sello de la renovación que requiere volver a proteger los datos frente al debilitamiento del hash. RFC 4998, secciones 4 y 5.

Al evaluar un archivo, pida recuperar un documento y validarlo con sus evidencias. Revise la política de renovación y las condiciones de exportación. El contrato debe establecer quién conserva los expedientes si cambia el servicio de firma y cómo podrán verificarse fuera de él.

El procedimiento se explica en cómo se preserva una firma digital a largo plazo. Incluya ese servicio en el plan de migración, con los documentos que cubre, el período de conservación y el responsable de las renovaciones.

La migración en las soluciones de Identik

En Identik integramos Firma Digital, Firma Electrónica, Sello de Tiempo y Archivo Digital, con Namirial como partner tecnológico. Para cada implementación, definimos cómo se firmarán los documentos, qué evidencias se conservarán y durante cuánto tiempo.

Iremos migrando los algoritmos de nuestras soluciones conforme lo indiquen las recomendaciones de seguridad y lo exijan las regulaciones aplicables. Coordinaremos los cambios con Namirial y con los certificadores que intervengan en cada servicio. Antes de incorporarlos, comprobaremos la compatibilidad de certificados, formatos y validadores. Para los documentos ya emitidos, revisaremos las evidencias y las renovaciones necesarias para su conservación.

Informaremos a cada cliente qué cambia en su servicio, cuándo estará disponible y si su integración necesita ajustes. Nuestro equipo coordinará las pruebas y acompañará la puesta en producción. El cliente contará con Identik para gestionar la transición y resolver las dudas sobre sus documentos y su operación.