La cripto-agilidad nunca se trató de computadores cuánticos

Casi todas las conversaciones que tengo sobre el futuro de la criptografía empresarial siguen el mismo guion. Algún día llega un computador cuántico. RSA y la criptografía de curva elíptica se rompen. Las organizaciones migran a algoritmos poscuánticos. Problema resuelto.

Los tres primeros pasos son correctos. Dediqué buena parte de este año a escribir sobre ellos y sostengo cada palabra. La migración poscuántica es necesaria, es urgente, y los reguladores ya la convirtieron en plazos.

El cuarto paso es el peligroso.

Supone que el cambio criptográfico es un evento único, con una causa conocida, un destino conocido y una fecha de fin. Supone que los algoritmos que elijamos en esta migración seguirán siendo aceptables mientras los necesitemos. Y que, si algún día dejan de serlo, tendremos años de aviso.

Los últimos cuatro años dicen otra cosa.

Cinco avisos. Cero computadores cuánticos.

Rainbow. Finalista de la competencia de firmas poscuánticas de NIST. En febrero de 2022, un solo artículo recuperó su clave secreta para un conjunto de parámetros en unas 53 horas en un portátil. Años de escrutinio público, dos rondas de selección, y después un fin de semana de cómputo. Nunca se estandarizó.

SIKE. NIST lo hizo avanzar a la cuarta ronda de su proceso poscuántico en julio de 2022. Menos de un mes después, unos investigadores lo rompieron con un ataque clásico en unos diez minutos en un solo núcleo. El ataque se apoyó en un resultado matemático de 1997 que nadie había relacionado con el esquema.

HAWK. Un esquema de firma basado en retículos que avanzó a la tercera ronda del proceso de firmas adicionales de NIST en mayo de 2026. Once semanas después, un análisis asistido por IA divulgado por el Frontier Red Team de Anthropic encontró una propiedad estructural que redujo a la mitad su tamaño efectivo de clave. Los autores retiraron el esquema al día siguiente. El ataque sigue siendo exponencial y específico de HAWK. Pero muestra algo nuevo: la velocidad a la que se encuentran debilidades también está cambiando.

Classic McEliece. Este es el que más importa, porque no es joven. Viene de un diseño de 1978, uno de los sistemas de clave pública más antiguos que tenemos. Su larga trayectoria era precisamente el argumento a su favor. El BSI alemán lo recomendaba desde 2020, e ISO lo estandarizó en junio de 2026. Luego, en cuestión de meses, una ola de criptoanálisis estructural derrumbó estimaciones de costo que se habían sostenido durante décadas. En septiembre de 2026, el BSI desaconsejó usarlo en desarrollos nuevos. El BSI fue cuidadoso al aclarar que no existe un ataque práctico. Classic McEliece no se rompió. Simplemente dejó de ser aceptable para uso nuevo.

RSA. En septiembre de 2026, unos investigadores ejecutaron a escala real una técnica de falsificación de firmas descrita por primera vez en 2007, usando como objetivo un módulo de seguridad de hardware real. No significa que RSA haya sido factorizado, y aplica a un modelo de ataque específico. Pero redujo entre 15 y 30 bits, en ese modelo, la estimación concreta de seguridad de uno de los algoritmos más desplegados de la historia. Una teoría de 2007 se volvió práctica en 2026.

Ninguno de estos casos necesitó un computador cuántico.

Para ser preciso: tres de los cinco eran candidatos, y detectar candidatos débiles es justamente para lo que existe un proceso de selección. ML-KEM y ML-DSA, los estándares finales de NIST, no se ven afectados por ninguno de estos resultados. Ese no es el punto.

El punto es que la evaluación de seguridad de los mecanismos criptográficos se mueve. A veces de golpe. Por razones que incluyen la computación cuántica, pero no se limitan a ella. Y se puede mover para mecanismos maduros, estandarizados y recomendados, igual que para los nuevos.

Los algoritmos no cambian de repente. Lo que cambia es nuestro conocimiento sobre su seguridad.

No es mi opinión

Quiero dejar claro que esto no es un relato de proveedor. Es la posición declarada de las instituciones que definen la práctica criptográfica, y es anterior por años a la ola poscuántica.

El trabajo de NIST sobre cripto-agilidad dice que los avances en computación, investigación criptográfica y criptoanálisis obligan periódicamente a reemplazar algoritmos que ya no ofrecen una seguridad adecuada. El mismo trabajo documenta lo lentos que han sido esos reemplazos: la transición completa de Triple DES a AES tomó 23 años.

El IETF lo formalizó ya en 2015 en el RFC 7696: los algoritmos envejecen y se debilitan con el tiempo, el momento de esos avances no se puede conocer de antemano, y el abandono de un algoritmo debería ocurrir antes de que llegue al punto de quiebre.

En otras palabras, la comunidad de estándares lleva una década tratando la obsolescencia criptográfica como algo que se gestiona antes de la falla, no después.

Roto no es el umbral que importa

Las discusiones de seguridad tienden a tratar la criptografía como algo binario. Seguro o roto.

Las empresas no viven en esa línea. Viven en la aceptabilidad. Y la aceptabilidad se puede retirar mucho antes de que algo se rompa.

La propia guía de NIST para transiciones de algoritmos, SP 800-131A, no clasifica los algoritmos como seguros o inseguros. Les asigna un estado: aceptable, obsoleto, uso heredado, no permitido. Y el mismo algoritmo puede tener estados distintos para operaciones distintas. Triple DES ya no puede cifrar, pero todavía puede descifrar. SHA-1 no puede generar firmas nuevas, pero todavía puede verificar las viejas.

Mire las fechas que ya están en el calendario. NIST propone declarar obsoletos los algoritmos vulnerables a la cuántica después de 2030 y no permitirlos después de 2035. Esas fechas aplican se haya demostrado o no un computador cuántico para entonces. La decisión del BSI sobre Classic McEliece muestra el mismo mecanismo funcionando en meses en lugar de años, con evidencia que se queda muy lejos de un ataque práctico.

Para una empresa, la obsolescencia criptográfica llega antes que la falla criptográfica.

Entonces, la pregunta que debe hacerse un CISO cambia. Ya no es "¿se rompió este algoritmo?".

Es "¿este mecanismo sigue siendo aceptable, para este uso, bajo los estándares y las políticas que nos aplican?".

Esa segunda pregunta tiene más respuestas posibles, cambia más seguido y la deciden personas fuera de su organización: organismos de estándares, agencias nacionales, reguladores, auditores, contrapartes. Una organización que solo puede reaccionar a la primera pregunta llega tarde por diseño.

La brecha de respuesta criptográfica

Si la aceptabilidad puede cambiar de repente y por razones que usted no controla, lo que determina su riesgo no es solo el cambio en sí. Es cuánto tiempo sigue dependiendo de un mecanismo después de que deja de ser aceptable.

A esto lo llamamos brecha de respuesta criptográfica (Cryptographic Response Gap). Va desde el momento en que cambia la evaluación, el estándar o el estado de un mecanismo para un uso dado, hasta el momento en que su organización terminó de remediarlo: ya no se aplica protección nueva con él, y los datos que protegía se trataron según la política.

La idea no es nueva. Bruce Schneier describió la "ventana de exposición" de las vulnerabilidades de software en 2000. La desigualdad de Mosca pone el tiempo de migración en el centro de la planificación poscuántica. La brecha de respuesta aplica la misma lógica a los mecanismos criptográficos, donde remediar significa reemplazar un mecanismo en cada sistema que depende de él. Por eso se mide en meses o años, no en días.

La brecha tiene varias partes: detectar que algo cambió, encontrar dónde se usa el mecanismo, decidir qué lo reemplaza, diseñar el cambio, desplegarlo y salir del mecanismo viejo. La mayoría de las organizaciones invierte en las dos primeras mediante programas de descubrimiento e inventario. Esa inversión es necesaria. Pero en una empresa típica, la parte más larga de la brecha es la ingeniería, el despliegue y la salida. Y esas las determina la arquitectura.

Esta es la parte que, creo, cambia la conversación. Dos organizaciones que usan exactamente los mismos algoritmos pueden enfrentar riesgos muy distintos. Una puede frenar el uso nuevo de un mecanismo en todo su parque con un cambio de política gobernado. La otra tiene que abrir un programa de varios años para hacer lo mismo.

El algoritmo determina su exposición el día del cambio. La arquitectura determina su exposición todos los días siguientes.

Migrar no es ser ágil

Hagámoslo concreto.

Una organización tiene 200 aplicaciones que usan RSA y criptografía de curva elíptica. Ejecuta una migración poscuántica excelente. Cada aplicación se analiza, se cambia su código, se introduce una librería nueva, se prueba, se certifica y se despliega con el algoritmo X. El programa toma tres años. Sale bien.

Al año siguiente, el algoritmo X deja de ser aceptable para uno de sus usos. Un resultado nuevo. Una guía nacional revisada. Una decisión de un regulador.

La organización ahora tiene que modificar otra vez las mismas 200 aplicaciones. El mismo análisis, la misma ingeniería, las mismas pruebas, la misma certificación, el mismo ciclo de despliegue.

Completó una migración criptográfica. No logró cripto-agilidad. Cambió el algoritmo. No cambió la arquitectura que hizo caro el cambio.

Por eso la migración poscuántica y la cripto-agilidad no deberían tratarse como el mismo proyecto. La migración responde "¿qué algoritmo usamos ahora?". La agilidad responde "¿cuánto costará cambiar esa respuesta otra vez?".

Una investigación reciente de IBM lo plantea de manera formal: cuando la elección del algoritmo se hace en cada punto de llamada, el costo de cada cambio de algoritmo se multiplica por el número de puntos de llamada.

Y una fuente más de falsa confianza: poder rotar claves no es lo mismo que poder cambiar de algoritmo. La rotación reemplaza el material de la clave. La agilidad de algoritmo cambia la correspondencia gobernada entre un uso, como "firmar facturas", y el mecanismo que lo resuelve. Se pueden rotar claves rutinariamente y aun así descubrir que cambiar un algoritmo es un programa de tres años.

Dónde vive realmente la brecha: sus datos, no sus canales

Cuando la gente escucha "cripto-agilidad", la mayoría piensa en TLS. Actualizar el protocolo, cambiar las suites de cifrado, pasar a intercambio de claves híbrido. Ese trabajo importa, y nada de esto argumenta en su contra. Pero no es donde la brecha de respuesta es más larga.

La criptografía de transporte se diseñó con la agilidad incorporada. Los algoritmos se negocian por sesión. Las claves de sesión son efímeras. Cuando una suite de cifrado deja de ser aceptable, la corrección vive en un conjunto relativamente pequeño de lugares: balanceadores de carga, gateways, servidores web, librerías que mantienen los fabricantes y las comunidades de código abierto. Se actualizan los extremos y la siguiente sesión usa el mecanismo nuevo. Sus aplicaciones de negocio normalmente ni lo notan.

Y mire otra vez los cinco casos. Ninguno obligó a nadie a reescribir su stack TLS. Tres eran candidatos que nunca se desplegaron. Los dos que tocan sistemas reales apuntan a otro lugar: Classic McEliece se valoraba precisamente como una opción conservadora para la confidencialidad de largo plazo, y la falsificación RSA se ejecutó contra un HSM que actuaba como oráculo de firma. Eso es criptografía de aplicación. Eso es criptografía de datos.

Los datos en reposo y los datos en uso no tienen ninguna de las ventajas del transporte.

Los datos en reposo están protegidos con claves de larga vida y siguen protegidos durante años. Registros financieros, archivos médicos, contratos, respaldos, logs. Cuando un mecanismo deja de ser aceptable, una sesión nueva no arregla nada. Los datos ya cifrados con el mecanismo viejo siguen ahí, y hay que volver a cifrarlos. Las firmas aplicadas hace años tienen que seguir siendo verificables, o hay que volver a firmarlas.

Los datos en uso son la criptografía dentro de su lógica de negocio. Cifrado de campos en una base de datos. Firma de documentos y transacciones. Tokens. Datos de pago. Aquí la elección del algoritmo suele vivir en el código de la aplicación, en las librerías que eligió el desarrollador, en los formatos que espera la aplicación. Ahí es exactamente donde vive el problema de las 200 aplicaciones.

La agilidad del transporte la resuelven en gran parte los protocolos. La agilidad de los datos no la resuelve nadie, salvo que usted la diseñe en su arquitectura.

Es el mismo argumento que planteé en el primer artículo de mi serie "Su actualización de TLS no lo va a salvar": la seguridad cuántica tiene que empezar en la capa de datos. Resulta que la cripto-agilidad también tiene que empezar ahí. Actualice sus canales, sí. Pero sus canales pueden cambiar en semanas. Sus datos y sus aplicaciones son donde un cambio de aceptabilidad se convierte en un programa de varios años.

La mitad de la que nadie habla: salir de la criptografía vieja

La mayoría de las conversaciones sobre cripto-agilidad se concentran en adoptar algoritmos nuevos. La mitad más difícil es dejar los viejos.

Cuando un mecanismo deja de ser aceptable para protección nueva, rara vez se deja de necesitarlo. Los archivos todavía hay que descifrarlos. Los contratos, facturas y logs firmados todavía hay que verificarlos. Los datos hay que volver a cifrarlos. La evidencia histórica tiene que seguir siendo verificable durante años.

Eso requiere estados entre "aprobado" y "prohibido", expresados por operación. No para despliegues nuevos. Obsoleto. Solo uso heredado. Solo migración, dentro de flujos gobernados de re-cifrado con fecha de fin. No permitido. La mayor parte de este vocabulario ya existe en las guías de NIST y del BSI.

Y dos cosas lo hacen funcionar en la práctica. El estado tiene que aplicarse donde se ejecuta la criptografía, para que un mecanismo en uso heredado no pueda usarse para cifrar aunque una aplicación lo pida. Y la organización tiene que poder demostrarlo: que un mecanismo dado no aplicó protección nueva desde una fecha dada.

Adoptar criptografía nueva es la mitad de la cripto-agilidad. Una salida controlada de la criptografía vieja es la otra mitad.

Agilidad bien hecha, y los críticos que tienen razón

La cripto-agilidad tiene críticos serios, y merecen una respuesta. Adam Langley sostuvo hace años que la extensibilidad agrega código, errores e interacciones peligrosas, y que tiende a fallar justo cuando se la necesita. El RFC 7696 advierte que la negociación abre ataques de degradación y que admitir demasiados algoritmos es dañino. El propio NIST reconoce que la agilidad agrega complejidad.

Tienen razón. Y apuntan a un tipo específico de agilidad, no en contra de la agilidad:

• Gobernada, no negociada. El mecanismo de un uso lo decide la política y se aplica de forma central, no se negocia por sesión entre partes que pueden ser manipuladas para elegir la opción más débil.
• Curada, no exhaustiva. Un conjunto pequeño de mecanismos aprobados por uso. Agilidad no significa admitirlo todo.
• Un solo punto de cambio, bien ejercitado. El cambio ocurre en un único punto gobernado y se usa rutinariamente, para que funcione cuando hace falta.
• La salida como operación propia. Los mecanismos obsoletos se retiran del uso nuevo de forma deliberada, no quedan tirados como respaldo.

Esta es la consecuencia arquitectónica de todo lo anterior. Si la seguridad criptográfica cambia con el tiempo, la elección del algoritmo no puede seguir siendo una decisión permanente embebida en cada aplicación. Las aplicaciones deberían expresar lo que necesitan, como proteger un registro o firmar un documento. La política debería decidir qué mecanismo resuelve esa necesidad. Y esa política debería pertenecer a quienes responden por el riesgo criptográfico y aplicarse donde se ejecutan las operaciones.

Por qué no puede esperar a que termine su migración PQC

Esta es la consecuencia incómoda de todo lo anterior. El peor momento para pensar en la cripto-agilidad es después de su migración poscuántica.

Si migra 200 aplicaciones fijando un algoritmo nuevo en el código de cada una, habrá pasado tres años recreando exactamente la arquitectura que hizo cara la migración. Solo que con matemática más nueva. El próximo cambio de aceptabilidad, cualquiera sea su causa, lo encontrará en el mismo lugar.

El mejor momento es ahora, mientras de todos modos va a tocar esas aplicaciones. Si va a abrir el código, ábralo una vez: reemplace el algoritmo embebido por una capacidad criptográfica estable gobernada por política. Así, la migración PQC pasa a ser la última vez que necesita tocar esa aplicación por razones criptográficas, no la primera de muchas.

Mientras tanto, tres cosas siguen creciendo cada día que espera.

Los datos que cifra hoy con los mecanismos de hoy son datos que quizás tenga que volver a cifrar mañana. El volumen solo aumenta.

Cada aplicación nueva que sus equipos construyen con criptografía embebida suma a la brecha de respuesta que tendrá que cerrar después.

Y los reguladores empezaron a hacer la pregunta de forma directa. El banco central de Arabia Saudita ahora exige a las instituciones financieras evaluar no solo qué activos criptográficos tienen, sino las restricciones, los desafíos y las dependencias de terceros que limitan su capacidad de cambiarlos. Saber lo que se tiene ya no alcanza. Se espera que sepa si puede moverlo.

Tres preguntas para el lunes por la mañana

El whitepaper incluye seis preguntas pensadas para revelar el largo de su brecha de respuesta antes de que lo haga un cambio real. Estas son las tres por las que yo empezaría:

1. Si el mecanismo que protege sus datos más críticos dejara de ser aceptable mañana, ¿cuántas aplicaciones tendría que modificar?
2. Si ese mecanismo protege datos almacenados por los próximos diez años, ¿puede volver a cifrarlos sin regresar a las aplicaciones que los crearon?
3. ¿Puede demostrar ante un auditor que un mecanismo no se usó para aplicar protección nueva desde una fecha dada?

Las organizaciones que pueden responder estas preguntas con evidencia están preparadas para la transición poscuántica, y para las transiciones que vendrán después. Las que no pueden, se están preparando para un cambio a la vez.

La verdadera pregunta

La migración poscuántica lo prepara para la transición criptográfica que todos ven venir. La cripto-agilidad lo prepara para las que nadie puede predecir.

El computador cuántico es un reloj. No es el único. El criptoanálisis clásico, la investigación asistida por IA, el cómputo más barato, la teoría que se vuelve práctica y, sobre todo, los estándares y los reguladores que cambian lo que es aceptable: todos corren con su propio calendario, y ninguno le va a avisar.

La pregunta no es si la criptografía va a cambiar. Va a cambiar.

La pregunta es cuánto de su empresa tiene que cambiar cuando lo haga.

Si la respuesta es "cada aplicación que toca datos sensibles", el momento de cambiar esa respuesta es ahora. No después de la migración. Durante ella. Empezando por la capa donde la brecha es más larga: la criptografía que protege sus datos en reposo y en uso.

El whitepaper completo, Crypto agility beyond the quantum clock, con la evidencia, el modelo de la brecha de respuesta y las seis preguntas, está disponible en inglés en la página de la solución de cripto-agilidad.

La cripto-agilidad es la primera propiedad para la que diseñamos ANKASecure© en ANKATech: las aplicaciones invocan capacidades estables, los algoritmos se gobiernan como política y la criptografía vieja se retira de forma deliberada, con evidencia.