Agilidad criptográfica más allá del reloj cuántico

Resumen ejecutivo

La mayoría de las conversaciones empresariales sobre el futuro de la criptografía siguen un único argumento. Un computador cuántico criptográficamente relevante llegará tarde o temprano, la criptografía RSA y de curva elíptica dejará de ser segura, y las organizaciones deben migrar a criptografía poscuántica (PQC) antes de que eso ocurra. Los ataques de tipo "capturar ahora, descifrar después" (harvest now, decrypt later) hacen que parte de ese riesgo sea presente hoy, y los gobiernos lo han convertido en plazos.

Ese argumento es correcto. También es incompleto. Describe una transición criptográfica, la que todos pueden ver venir, e invita a una conclusión peligrosa: que una vez terminada la migración a PQC, el problema está resuelto.

La evidencia de los últimos cuatro años apunta en otra dirección. Rainbow, finalista del proceso poscuántico de NIST, cayó ante un ataque clásico que recuperaba claves en un portátil. SIKE fue roto en minutos en un solo núcleo, menos de un mes después de que NIST lo hiciera avanzar a la cuarta ronda. HAWK, candidato de firma en la Ronda 3, fue retirado en julio de 2026 después de que un análisis asistido por IA redujera a la mitad su tamaño efectivo de clave. Classic McEliece, un diseño de 1978 estandarizado por ISO/IEC en junio de 2026, fue objeto de una ola tan rápida de criptoanálisis estructural que en septiembre de 2026 la BSI de Alemania desaconsejó su uso en nuevos desarrollos, aunque confirmó que no existe ningún ataque práctico. Y una técnica de falsificación RSA descrita en 2007 se ejecutó a escala real contra un módulo de seguridad de hardware en 2026. Ninguno de estos eventos requirió un computador cuántico.

La migración poscuántica prepara a las organizaciones para una transición criptográfica que pueden ver venir. La agilidad criptográfica las prepara para los cambios criptográficos que no pueden predecir.

Este documento plantea cuatro argumentos. Primero, la seguridad criptográfica es una evaluación en evolución, no una propiedad permanente, y los principales organismos de estándares del mundo lo han dicho durante años. Segundo, un algoritmo no necesita estar roto para volverse inutilizable para una empresa: los estándares, los reguladores y las políticas pueden retirar su aceptabilidad antes de que exista cualquier ataque práctico. Tercero, lo que determina el riesgo empresarial no es solo si un mecanismo se vuelve inaceptable, sino cuánto tiempo sigue dependiendo de él la organización después, un periodo que llamamos la Brecha de Respuesta Criptográfica. Cuarto, una organización puede completar una migración criptográfica completa y aun así no ser criptoágil, porque cambiar el algoritmo no cambia la arquitectura que hizo costoso el cambio.

De estos argumentos, el documento deriva una consecuencia arquitectónica. Si la seguridad criptográfica cambia con el tiempo, la elección del algoritmo no debería seguir siendo una decisión permanente incrustada en cada aplicación. Debería gobernarse como política, aplicarse mediante una abstracción estable y acompañarse de una forma controlada de salir de la criptografía antigua, porque adoptar nuevos algoritmos es solo la mitad de la agilidad criptográfica.

Este documento es complemento del whitepaper The Cryptographic Control Plane, que presenta el marco CAPA (Crypto Agility Posture Architecture) ^[22]. La agilidad criptográfica es el primero de los cinco pilares de CAPA. Este documento la desarrolla en el contexto donde con más frecuencia se malinterpreta: la creencia de que la transición poscuántica es el último cambio criptográfico que una organización tendrá que hacer.

Cómo leer la evidencia de este documento

Cada afirmación de este documento pertenece a una de cuatro categorías, y el texto indica a cuál. Las citas entre corchetes remiten a las referencias al final del documento.

Nunca atribuimos nuestras interpretaciones a las instituciones que citamos. NIST no dice que las empresas necesiten un Plano de Control Criptográfico. NIST define el problema de la agilidad criptográfica, la IETF ha exigido agilidad de algoritmos durante una década, la investigación reciente muestra varias causas distintas de cambio criptográfico, y nosotros derivamos una consecuencia arquitectónica de las tres.

La suposición cómoda

Toda transición criptográfica está moldeada por la historia que las organizaciones se cuentan sobre por qué está ocurriendo. La historia de la transición poscuántica es inusualmente clara, y esa claridad es a la vez su fortaleza y su limitación.

2.1 Lo que la narrativa cuántica acierta

La amenaza cuántica a la criptografía de clave pública es real y se entiende bien. Un computador cuántico suficientemente capaz que ejecute el algoritmo de Shor rompería RSA, Diffie-Hellman de campo finito y los esquemas de curva elíptica, que en conjunto protegen la mayor parte del intercambio de claves y de las firmas digitales en uso hoy. Como el tráfico cifrado y los datos almacenados pueden capturarse ahora y descifrarse después, el riesgo para la información de larga vida comienza antes de que exista una máquina así.

Los gobiernos han convertido esta amenaza en calendarios. El plan de transición de NIST depreca los algoritmos de clave pública vulnerables a la computación cuántica (RSA, ECDSA, EdDSA, Diffie-Hellman y MQV) después de 2030 y los prohíbe después de 2035 ^[5]. En Estados Unidos, la Orden Ejecutiva 14412 de junio de 2026 exige que los activos de alto valor y los sistemas de alto impacto pasen a establecimiento de claves poscuántico a finales de 2030 y a firmas poscuánticas a finales de 2031, citando explícitamente a adversarios que recolectan datos hoy para descifrarlos más adelante ^[6]. El NCSC del Reino Unido pide a las organizaciones completar el descubrimiento y la planificación para 2028, las migraciones prioritarias para 2031 y la migración completa para 2035 ^[7], y la hoja de ruta coordinada de la Unión Europea converge en hitos similares ^[8].

Nada de esto se pone en duda aquí. La migración poscuántica es necesaria, es urgente, y las organizaciones que la retrasan están acumulando riesgo.

2.2 Lo que la narrativa omite

La versión cómoda de la historia tiene una forma sencilla:

El error está en el último paso. Trata el cambio criptográfico como un evento único con una causa conocida, un destino conocido y una fecha de fin. Supone que los algoritmos elegidos en la migración seguirán siendo aceptables durante todo el tiempo que la organización los necesite, y que si alguna vez dejan de serlo, habrá años de aviso.

Ninguna de las dos suposiciones está respaldada por la historia de la criptografía, y los eventos de los últimos cuatro años han hecho que el punto sea difícil de ignorar.

2.3 Lo cuántico no es el único reloj

Un computador cuántico criptográficamente relevante es una fuerza que puede cambiar la evaluación de seguridad de un mecanismo criptográfico. No es la única. La evaluación también puede cambiar debido a:

• Nuevo criptoanálisis clásico, que encuentra estructura que el análisis anterior pasó por alto.
• Avances en la capacidad de cómputo clásica, que abaratan los ataques conocidos.
• Nuevas formas de explotar capacidades existentes, que convierten un ataque teórico en uno práctico bajo condiciones de acceso realistas.
• La IA aplicada a la investigación matemática y al criptoanálisis, que cambia la velocidad a la que se encuentran debilidades.
• Cambios en estándares, recomendaciones y políticas, que pueden retirar la aceptabilidad de un mecanismo antes de que esté roto.
• La computación cuántica, eventualmente.

La migración poscuántica es una transición conocida. El cambio criptográfico es una condición permanente.

La seguridad criptográfica es una evaluación en evolución

La afirmación de que la seguridad criptográfica cambia con el tiempo no es una postura de marketing. Es la posición declarada de las instituciones que definen la práctica criptográfica, y antecede en muchos años a la actual ola de atención poscuántica.

3.1 Lo que dice NIST

El proyecto Crypto Agility de NIST afirma que los avances en capacidades de cómputo, investigación criptográfica y técnicas criptoanalíticas crean periódicamente la necesidad de reemplazar algoritmos que ya no ofrecen una seguridad adecuada para sus casos de uso ^[2]. Su white paper sobre agilidad criptográfica, actualizado en junio de 2026, define la agilidad criptográfica como las capacidades necesarias para reemplazar y adaptar algoritmos criptográficos en protocolos, aplicaciones, software, hardware, firmware e infraestructuras, preservando la seguridad y la continuidad de las operaciones ^[1].

El mismo documento muestra lo lentos que han sido esos reemplazos en la práctica. La transición completa de Triple DES a AES tomó 23 años. SHA-1, cuya debilidad ante colisiones se identificó en 2005, siguió aceptándose en circunstancias limitadas mucho tiempo después por razones de interoperabilidad. Los tamaños mínimos de clave RSA pasaron de 1024 a 2048 bits a medida que mejoraron la factorización y el cómputo ^[1]. El plan de transición poscuántica de NIST añade que las migraciones criptográficas anteriores han tomado más de una década, y que la migración poscuántica probablemente tomará al menos lo mismo ^[5].

3.2 Lo que la IETF ha dicho desde 2015

La IETF formalizó la misma posición en el RFC 7696, una Best Current Practice (BCP 201) publicada en noviembre de 2015. Afirma que los algoritmos criptográficos envejecen y se debilitan con el tiempo, a medida que se desarrollan nuevas técnicas criptoanalíticas y mejoran las capacidades de cómputo, y que el momento y el alcance de esos avances no pueden conocerse de antemano. Por lo tanto, los protocolos necesitan mecanismos para migrar de un algoritmo a otro ^[3].

El RFC 7696 va más allá, de una forma que importa a las empresas. Recomienda que la transición para abandonar un algoritmo ocurra antes de que los algoritmos del conjunto actual se hayan debilitado hasta el punto de ruptura ^[3]. También define niveles de exigencia diseñados para señalar, con anticipación, que se espera degradar o deprecar un algoritmo. En otras palabras, la comunidad de estándares ha tratado desde hace tiempo la obsolescencia como algo que se gestiona antes de la falla, no después.

3.3 Los algoritmos no avisan

En conjunto, estas posiciones llevan a una formulación que este documento usa a lo largo de todo su desarrollo. Es nuestra formulación, no una frase atribuida a NIST ni a la IETF:

Los algoritmos no cambian de repente. Nuestro conocimiento sobre su seguridad sí puede hacerlo.

No hay razón para esperar un declive ordenado que vaya de completamente seguro a ligeramente más débil, a una advertencia formal, a seis meses de vida restante. Un solo resultado puede mover de forma abrupta la evaluación de un mecanismo, y los casos del siguiente capítulo muestran exactamente eso. Por lo tanto, una organización no puede suponer que siempre tendrá varios años para reaccionar.

Cinco advertencias del mundo real

Los siguientes cinco casos se seleccionaron porque cada uno ilustra una forma distinta en que puede cambiar la evaluación de un mecanismo criptográfico. No se presentan como evidencia de que la criptografía esté rota, ni de que los estándares poscuánticos sean inseguros. Son evidencia de que la evaluación se mueve, y de que se mueve según su propio calendario.

Ninguno de ellos requirió un computador cuántico.

Esta observación no disminuye el riesgo cuántico. Amplía el modelo de riesgo.

4.1 Rainbow: un finalista cae en un portátil

Rainbow fue uno de los tres finalistas de firma digital en la tercera ronda del proceso de estandarización poscuántica de NIST. En febrero de 2022, Ward Beullens publicó nuevos ataques que superaban a todos los ataques conocidos hasta entonces para cada conjunto de parámetros presentado a NIST. Para los parámetros de nivel 1 de la propuesta de segunda ronda, su ataque recuperaba la clave secreta en unas 53 horas en promedio en un portátil estándar. Estimó que recuperar una clave para los parámetros de nivel 1 de la tercera ronda sería solo unas 28 veces más costoso ^[9]. Rainbow no fue seleccionado para estandarización.

Rainbow es el ejemplo más nítido de una reevaluación abrupta. Un esquema que había sobrevivido años de escrutinio público y dos rondas de selección dejó de ser, tras un solo artículo, un candidato que alguien fuera a desplegar.

4.2 SIKE: roto semanas después de avanzar

SIKE era un mecanismo de encapsulamiento de claves basado en isogenias que NIST hizo avanzar a la cuarta ronda de su proceso en julio de 2022, como candidato para estandarización adicional. Menos de un mes después, Wouter Castryck y Thomas Decru publicaron un ataque clásico de recuperación de claves que, en la versión revisada de su artículo, rompe SIKEp434, el conjunto de parámetros de nivel 1, en unos diez minutos en un solo núcleo ^[10]. El ataque se apoyó en un resultado matemático de 1997 de Ernst Kani cuyas consecuencias para el esquema no se habían reconocido durante años de análisis público.

SIKE ilustra lo corto que puede ser el intervalo entre la confianza institucional y la falla práctica.

4.3 HAWK: criptoanálisis asistido por IA

HAWK era un esquema de firma basado en retículos. El 14 de mayo de 2026, NIST anunció que estaba entre los nueve candidatos que avanzaban a la tercera ronda de su proceso de firmas digitales adicionales ^[11]. El 28 de julio de 2026, el Frontier Red Team de Anthropic divulgó un ataque mejorado de recuperación de claves contra HAWK, encontrado con su modelo Claude Mythos Preview, que explota una propiedad estructural hasta entonces desconocida de los retículos de HAWK y reduce el tamaño efectivo de clave a la mitad. Para HAWK-256, el costo esperado del ataque cayó de unos 264 a unos 238. El ataque sigue siendo de tiempo exponencial y, según Anthropic, es específico de HAWK y no afecta a otros candidatos poscuánticos de NIST ni a la criptografía basada en retículos en general. Los autores de HAWK recibieron el resultado por anticipado, en junio ^[12]. El 29 de julio de 2026, el equipo de HAWK retiró el esquema, y NIST registró que el retiro se produjo tras el anuncio de Anthropic ^[11].

HAWK nunca se desplegó, así que su retiro no tuvo impacto operativo. Su relevancia es otra: muestra que la propia velocidad a la que se descubren debilidades está cambiando. Aquí importa una caracterización cuidadosa. El resultado fue una mejora exponencial sobre un esquema candidato, verificada con código de demostración y divulgada en coordinación con sus autores, no una demostración general de que la IA pueda romper la criptografía moderna.

4.4 Classic McEliece: la madurez no congela la evaluación

Classic McEliece es, conceptualmente, el más importante de los cinco casos, porque no es un esquema joven. Deriva del criptosistema McEliece publicado en 1978, uno de los diseños de clave pública más antiguos, y su largo historial de análisis era precisamente su principal argumento. NIST lo evaluó en la cuarta ronda de su proceso y, en marzo de 2025, seleccionó HQC en su lugar, citando el tamaño de las claves públicas de Classic McEliece y el limitado interés en su despliegue, no una debilidad de seguridad ^[16]. ISO/IEC estandarizó Classic McEliece en junio de 2026 ^[15], y la BSI de Alemania lo recomienda con parámetros seleccionados en su Directriz Técnica TR-02102-1 desde 2020 ^[14].

En los meses siguientes, el análisis estructural de McEliece cambió más rápido que en cualquier otro momento de su historia. El propio resumen de la BSI, publicado el 29 de septiembre de 2026, describe el cambio ^[14]. Durante décadas, el mejor ataque estructural conocido de recuperación de claves tenía un costo estimado superior a 23000 incluso para los parámetros más pequeños. Los distinguidores publicados en 2025 y 2026 llevaron las estimaciones para los conjuntos de parámetros recomendados en TR-02102-1 a 2683 y luego a 2550. En agosto de 2026, Ghoshal, Ishai, Jain y Sun presentaron un distinguidor de complejidad asintóticamente cuasipolinomial, que estiman entre 2120 y 2124 operaciones para esos parámetros, junto con un método heurístico de recuperación de claves de 2140 a 2148 ^[13][14]. En septiembre, un nuevo preprint afirmó lograr la recuperación de claves con un costo de 299 a 2102 ^[14].

Los autores del resultado cuasipolinomial afirman que sus ataques concretos aún no son prácticos ^[13]. La BSI subraya que los artículos más recientes no han completado la revisión por pares, que sus modelos de costo, incluidos los costos de acceso a memoria, todavía deben examinarse con cuidado, y que hasta ahora los resultados no permiten un ataque práctico contra los conjuntos de parámetros recomendados ^[14]. Por lo tanto, es incorrecto decir que Classic McEliece ha sido roto.

Aun así, la BSI concluyó que Classic McEliece no debería usarse por ahora en nuevos desarrollos ni al planificar nuevas aplicaciones criptográficas. Su recomendación se limita al uso híbrido, combinado con un esquema clásico de modo que ambos deban romperse para recuperar la clave, y la entrada de la directriz se revisará a comienzos de 2027. La BSI añade que los demás esquemas poscuánticos recomendados, ML-KEM y FrodoKEM, así como HQC, no se ven afectados, y que los nuevos resultados subrayan la importancia de la agilidad criptográfica durante la migración porque "nunca pueden descartarse avances criptoanalíticos" ^[14].

Classic McEliece no fue roto. Se volvió inaceptable para nuevos usos. Esa distinción es el tema del siguiente capítulo.

4.5 RSA: cuando la teoría se vuelve práctica

El quinto caso se refiere a la criptografía clásica y exige una precisión particular. En septiembre de 2026, Shea, Haller, Suhl, Heninger y Thomé informaron sobre una implementación a escala real de un algoritmo publicado en 2007 por Joux, Naccache y Thomé ^[17]. Con acceso temporal a un oráculo de firma o descifrado RSA sin relleno (raw), un atacante puede luego falsificar firmas RSA sin factorizar el módulo y sin extraer la clave privada. Los investigadores usaron un módulo de seguridad de hardware real como oráculo: 232 consultas, unos 1.380 años-núcleo de CPU de cómputo y cinco meses calendario. Después de ese precómputo, cada firma elegida podía falsificarse fuera de línea por unos 180 años-núcleo. Estiman que, en este modelo de ataque, la seguridad concreta de RSA de 1024 a 4096 bits es de 15 a 30 bits inferior a lo que sugieren las estimaciones basadas en factorización ^[17].

Este resultado no significa que RSA-1024, y mucho menos RSA en general, haya sido factorizado o roto. Se aplica a un modelo específico en el que un atacante puede obtener operaciones RSA sin relleno de un oráculo; el resumen del artículo no establece su aplicabilidad a esquemas de firma con relleno como PKCS#1 v1.5 o PSS. Su relevancia es otra: el cambio criptográfico no tiene que venir de la computación cuántica, ni siquiera de nuevas matemáticas. Puede venir de volver práctico, a una escala relevante, algo que era teórico, y las estimaciones de seguridad que dependían de un modelo de ataque pueden moverse cuando otro se vuelve realista.

4.6 Lo que muestran los cinco casos, y lo que no

Tres de los cinco esquemas eran candidatos en un proceso de selección y nunca llegaron a ser estándares. Se podría argumentar, con razón, que eso es el proceso de selección funcionando como se espera. Los estándares finalizados de NIST, ML-KEM y ML-DSA, no se ven afectados por ninguno de estos resultados, y nada en este documento sugiere lo contrario.

Pero el argumento de este documento no depende de que los estándares fallen. Depende de una observación más acotada y mejor sustentada: la evaluación de los mecanismos criptográficos cambia, a veces de forma abrupta, por razones que incluyen la computación cuántica pero no se limitan a ella, y puede cambiar tanto para mecanismos maduros, estandarizados y ampliamente recomendados como para candidatos nuevos. Classic McEliece pasó de estándar ISO a "no para nuevos desarrollos" en unos tres meses. El resultado del oráculo de firma RSA revisó la seguridad concreta de uno de los algoritmos más desplegados de la historia. Una arquitectura empresarial que supone que los algoritmos poscuánticos que selecciona hoy seguirán siendo aceptables durante toda la vida de sus sistemas está haciendo una apuesta que la evidencia no respalda.

Roto no es el umbral de la empresa

Las discusiones de seguridad suelen tratar la criptografía como algo binario: un algoritmo es seguro o está roto. Las empresas no operan en esa frontera. Operan sobre la aceptabilidad, y la aceptabilidad puede retirarse mucho antes de que algo se rompa.

5.1 La aceptabilidad es un estado, no una propiedad

La NIST SP 800-131A, la guía que NIST usa para gestionar las transiciones de algoritmos, no clasifica los algoritmos como seguros o inseguros. Les asigna un estado ^[4]:

Un mismo mecanismo puede tener estados distintos para operaciones distintas. Según la SP 800-131A, el cifrado con Triple DES de tres claves estuvo deprecado hasta 2023 y quedó no permitido después, mientras que el descifrado sigue permitido como uso heredado. SHA-1 no está permitido para generar firmas digitales, salvo donde una guía de protocolo específica lo autorice, pero sí se permite como uso heredado para verificarlas ^[4]. Por lo tanto, la aceptabilidad es una propiedad de un mecanismo, para un propósito, en un momento dado.

5.2 Obsolescencia por política

Varios de los cambios criptográficos de mayor consecuencia que enfrentarán las empresas en la próxima década son decisiones de política, no resultados criptoanalíticos. La deprecación propuesta por NIST de los algoritmos vulnerables a la computación cuántica después de 2030, y su prohibición después de 2035, se aplicarán en esas fechas se haya demostrado o no un computador cuántico criptográficamente relevante ^[5]. La Orden Ejecutiva 14412 fija sus propios plazos de la misma manera ^[6]. La decisión de la BSI sobre Classic McEliece muestra el mismo mecanismo operando en una escala de tiempo mucho más corta y en respuesta a evidencia que se queda muy lejos de un ataque práctico ^[14].

Para una empresa, la obsolescencia criptográfica puede preceder a la falla criptográfica.

5.3 La pregunta que debería hacerse un CISO

La consecuencia práctica es un cambio en la pregunta que la gestión del riesgo criptográfico tiene que responder. La pregunta tradicional es:

¿El algoritmo ha sido roto?

La pregunta que realmente determina las obligaciones de una empresa es:

¿Este mecanismo sigue siendo aceptable, para este uso, según los estándares y políticas que nos aplican?

La segunda pregunta tiene más respuestas posibles, su respuesta cambia con más frecuencia, y la deciden partes fuera del control de la organización: organismos de estándares, agencias nacionales, reguladores sectoriales, auditores y contrapartes. Una organización que solo puede reaccionar a la primera pregunta llega tarde por estructura.

La brecha de respuesta criptográfica

Si la aceptabilidad puede cambiar de forma abrupta y por razones fuera del control de la organización, la variable que determina la exposición empresarial no es solo el cambio en sí. Es cuánto tiempo sigue dependiendo la organización de un mecanismo después de que ese mecanismo deja de ser aceptable.

6.1 Definición

Definimos la Brecha de Respuesta Criptográfica como el intervalo entre dos momentos:

• T0, cuando cambia, para un uso determinado, la evaluación de seguridad, el estándar aplicable o el estado de uso aceptable de un mecanismo criptográfico; y
• T1, cuando la organización completa la remediación para ese uso, lo que significa que el mecanismo ya no se usa para aplicar nueva protección y que la información que protegía se ha tratado conforme a la política.

El riesgo criptográfico no depende solo de si un mecanismo se vuelve inaceptable. También depende de cuánto tiempo sigue dependiendo la organización de él después de que eso ocurre.

6.2 De dónde proviene el concepto

La Brecha de Respuesta Criptográfica es una especialización de ideas que ya existen, y debe leerse así. En 2000, Bruce Schneier describió la ventana de exposición: el periodo durante el cual una vulnerabilidad puede explotarse, desde su descubrimiento hasta que se instalan los parches, y argumentó que el riesgo crece tanto con su duración como con el número de personas capaces de explotarla ^[18]. En la planificación poscuántica, la desigualdad de Mosca, que NIST usa en su plan de transición, compara la vida útil de los datos más el tiempo necesario para migrar con el tiempo que falta para que exista un computador cuántico; el tiempo de migración es una variable central de ese análisis ^[5].

La Brecha de Respuesta Criptográfica toma la estructura de la primera y la variable de tiempo de migración de la segunda, y se diferencia de ambas en dos aspectos. Su detonante es cualquier cambio de aceptabilidad, no solo una falla explotable y no solo la llegada de un computador cuántico. Y su remediación no es un parche del proveedor, sino el reemplazo de un mecanismo en todos los sistemas que dependen de él, razón por la cual suele medirse en meses o años y no en días. No encontramos un término existente para este intervalo preciso; lo proponemos como un lente práctico, no como un nuevo estándar.

6.3 Qué determina la duración de la brecha

La brecha es la suma de varias actividades, cada una de las cuales puede ser corta o larga según la arquitectura más que según el esfuerzo:

La mayoría de las organizaciones invierte en acortar las dos primeras actividades mediante programas de descubrimiento e inventario. Esas inversiones son necesarias. Pero en una empresa típica, la parte más larga de la brecha está en la ingeniería, el despliegue y la salida, y estas están determinadas por la arquitectura.

6.4 Por qué la brecha, y no el algoritmo, es la variable empresarial

Una organización no puede controlar cuándo un mecanismo se vuelve inaceptable. Sí puede controlar cuán larga será su brecha cuando eso ocurra. Dos organizaciones que usan exactamente los mismos algoritmos enfrentan riesgos muy distintos si una puede detener el uso nuevo de un mecanismo en todo su entorno mediante un cambio gobernado y la otra debe abrir un programa de varios años para hacer lo mismo. La elección del algoritmo determina la exposición de la organización el día del cambio; la arquitectura determina su exposición cada día posterior.

El problema de las 200 aplicaciones

La diferencia entre migración y agilidad se ve con mayor facilidad en un único ejemplo, deliberadamente sencillo.

7.1 Migración no es agilidad

Considere una organización con 200 aplicaciones que usan criptografía RSA y de curva elíptica. Ejecuta una migración poscuántica bien hecha: cada aplicación se analiza, se modifica su código, se introduce una nueva librería criptográfica, la aplicación se prueba y se certifica, y se despliega en producción usando el Algoritmo X. El programa toma tres años y tiene éxito.

Ahora suponga que, al año siguiente, el Algoritmo X deja de ser aceptable para uno de sus usos: un nuevo resultado, una directriz nacional revisada, la decisión de un regulador sectorial. La organización debe ahora modificar de nuevo las mismas 200 aplicaciones, pasando por el mismo ciclo de análisis, ingeniería, pruebas, certificación y despliegue.

La organización completó una migración criptográfica. No necesariamente logró agilidad criptográfica. Cambió el algoritmo; no cambió la arquitectura del problema.

Esta es la razón central por la que la migración poscuántica y la agilidad criptográfica no deberían tratarse como el mismo proyecto. La migración responde a la pregunta de qué algoritmo usar a continuación. La agilidad responde a la pregunta de cuán costoso será cambiar esa respuesta otra vez.

Si mañana el mecanismo criptográfico que protege su negocio se volviera inaceptable, ¿cuántas aplicaciones tendría que modificar para reemplazarlo?

7.2 El costo del acoplamiento

Trabajos académicos recientes sobre agilidad criptográfica a nivel de aplicación plantean el mismo punto de manera formal. Rameshan y Messmer, de IBM Research, proponen un marco de evaluación que mide qué tan estrechamente están acopladas las aplicaciones a algoritmos y proveedores específicos. Muestran que, en un sistema con agilidad mínima, el costo de migrar a un nuevo algoritmo crece con el número de lugares donde se crean operaciones y claves criptográficas, multiplicado por el número de parámetros que difieren entre el mecanismo antiguo y el nuevo. Al evaluar PKCS#11, OpenSSL 3.0, la Java Cryptography Architecture, Google Tink, AWS KMS y HashiCorp Vault Transit, encuentran brechas recurrentes, entre ellas la ausencia de una autoridad de gobierno sobre las decisiones criptográficas ^[19].

El ejemplo de las 200 aplicaciones es ilustrativo, no un conjunto de datos. Pero el mecanismo que describe es general: mientras la elección del algoritmo se haga en el punto de invocación, cada cambio de algoritmo cuesta un múltiplo del número de puntos de invocación.

7.3 La rotación de claves no es agilidad de algoritmos

Una fuente frecuente de falsa confianza es suponer que una organización capaz de rotar claves también es capaz de cambiar algoritmos. Son capacidades distintas, regidas por guías distintas. Los estándares de gestión de claves tratan el reemplazo de claves mediante criptoperiodos y periodos de uso como una función del ciclo de vida ^[21], mientras que las transiciones de algoritmos se gestionan mediante cambios de estado como los descritos en la SP 800-131A ^[4].

La pregunta arquitectónica que subyace a las tres columnas es si el algoritmo sigue acoplado a la aplicación. Si lo está, la rotación puede ser rutinaria y la migración seguirá siendo un programa.

Arquitectura para el cambio criptográfico

Si la seguridad criptográfica es una evaluación en evolución, la consecuencia arquitectónica se sigue directamente. Esta es nuestra interpretación, coherente con las instituciones citadas en este documento pero no atribuida a ellas:

La elección del algoritmo no debería seguir siendo una decisión permanente a nivel de aplicación.

8.1 Separar la intención criptográfica del mecanismo criptográfico

El documento de NIST sobre agilidad criptográfica describe el primer componente: una API criptográfica que separa la implementación de las aplicaciones de la implementación de los algoritmos criptográficos, de modo que las aplicaciones puedan hacer las mismas llamadas mientras cambia el algoritmo que hay detrás, y que algoritmos antiguos y nuevos puedan coexistir durante una transición ^[1]. El whitepaper The Cryptographic Control Plane describe el mismo principio a escala empresarial como la separación entre la intención criptográfica y la ejecución criptográfica: las aplicaciones expresan lo que necesitan, como proteger un registro o firmar un documento, y la infraestructura determina cómo ^[22].

8.2 Hacer de la política el punto de decisión

Una abstracción por sí sola no crea agilidad; crea un lugar donde puede tomarse una decisión. NIST describe cómo una política de algoritmos definida por un administrador puede bloquear las llamadas a algoritmos deprecados y al mismo tiempo permitir el descifrado de datos almacenados, y cómo la política criptográfica puede expresarse como un perfil consumible por máquinas, desplegado con herramientas automatizadas ^[1]. La decisión sobre qué mecanismo sirve a qué uso, y bajo qué condiciones, pertenece a esa política, cuyo dueño son las personas responsables del riesgo criptográfico, y se aplica donde se ejecutan las operaciones criptográficas.

8.3 Agilidad sin negociación: respuesta a los críticos

La agilidad criptográfica tiene críticos serios, y una arquitectura creíble debe responderles. Adam Langley argumentó en 2016 que los mecanismos de extensibilidad añaden código, errores e interacciones peligrosas, que tienden a fallar justo cuando por fin se necesitan, y que los protocolos deberían concentrar la extensibilidad en un solo lugar y mantenerla en uso ^[20]. El propio RFC 7696 advierte que la negociación compleja crea oportunidades para ataques de degradación y que soportar demasiados algoritmos es perjudicial, porque las opciones débiles persisten y son difíciles de eliminar ^[3]. NIST reconoce que dar cabida a la agilidad añade complejidad y puede aumentar la superficie de ataque ^[1].

Estas críticas son correctas, y apuntan hacia un tipo específico de agilidad, no hacia el abandono de la agilidad:

• Gobernada, no negociada. El mecanismo para un uso dado lo decide la política y se aplica de forma centralizada, no se negocia por sesión entre partes que podrían ser manipuladas para elegir la opción más débil.
• Curada, no exhaustiva. La política admite un conjunto reducido de mecanismos aprobados para cada uso; agilidad no significa soportarlo todo.
• Un solo punto de articulación, bien ejercitado. El cambio se concentra en un único punto gobernado y se usa de forma rutinaria, para que funcione cuando se necesite.
• La salida como operación de primer nivel. Los mecanismos deprecados se retiran deliberadamente del uso nuevo, en lugar de quedar como alternativas de respaldo.

8.4 Lo híbrido como cobertura

El caso de Classic McEliece también muestra el valor de las construcciones híbridas, en las que un mecanismo poscuántico se combina con uno clásico de modo que ambos deban romperse. La BSI señala que su recomendación de desplegar criptografía poscuántica en modo híbrido ha demostrado su valor, porque el impacto de un esquema debilitado queda mitigado ^[14]. El despliegue híbrido no sustituye a la agilidad, pero compra tiempo, y es la agilidad la que hace práctico introducir, ajustar y finalmente retirar las configuraciones híbridas.

La adopción es solo la mitad de la agilidad criptográfica

La mayoría de las discusiones sobre agilidad criptográfica se centran en adoptar nuevos algoritmos. La mitad más difícil es abandonar los antiguos.

9.1 Obsolescencia no significa eliminación

Cuando un mecanismo deja de ser aceptable para proteger información nueva, la organización rara vez deja de necesitarlo. Los archivos cifrados aún deben descifrarse. Los contratos, facturas y registros firmados aún deben verificarse. Los datos deben recuperarse, migrarse, recifrarse o refirmarse con nuevos mecanismos, y la evidencia histórica debe seguir siendo verificable durante años. NIST plantea el mismo punto: reemplazar un algoritmo de firma requiere un mecanismo para manejar los documentos ya firmados con él, y reemplazar un algoritmo de cifrado requiere un mecanismo para manejar los datos ya cifrados con él ^[1].

Adoptar nueva criptografía es solo la mitad de la agilidad criptográfica. Las organizaciones también necesitan una forma controlada de salir de la criptografía antigua.

9.2 Un ciclo de vida de estados criptográficos

Una salida controlada requiere estados entre "aprobado" y "prohibido", y esos estados deben expresarse por operación. La terminología existente ya cubre la mayor parte de lo necesario, y recomendamos adoptarla en lugar de inventar un vocabulario nuevo. La tabla relaciona los estados que necesita una empresa con referencias existentes, y señala el que proponemos como extensión.

Dos propiedades hacen que este ciclo de vida sea operativo y no solo descriptivo. El estado debe aplicarse donde se ejecutan las operaciones criptográficas, de modo que un mecanismo en uso heredado no pueda usarse para cifrar o firmar aunque una aplicación lo solicite. Y la organización debe poder demostrar el estado: que un mecanismo dado no se ha usado para aplicar nueva protección desde una fecha determinada, y que el uso heredado restante está confinado a los flujos que permite la política.

9.3 Modernizar lo que ya está protegido

La salida solo está completa cuando se ha tratado la información protegida con el mecanismo antiguo. Para datos con periodos de retención largos, eso significa recifrarlos con mecanismos aceptables; para firmas de larga vida, puede significar refirmar o añadir nueva evidencia. Cuando este trabajo depende de las aplicaciones que crearon los datos, se convierte en otro programa multiaplicación. Cuando puede realizarlo una infraestructura gobernada, de forma progresiva y sin recrear la información subyacente, se convierte en un proceso operativo ^[22].

De la migración PQC a la preparación criptográfica continua

El objetivo que se desprende de este análisis no es una migración completada. Es un estado en el que la organización puede absorber cambios en la aceptabilidad criptográfica, por cualquier causa, con una brecha de respuesta corta y predecible.

10.1 Correspondencia entre la brecha de respuesta y la madurez CAPA

El modelo de madurez CAPA descrito en el whitepaper The Cryptographic Control Plane ^[22] puede leerse a través del lente de la brecha de respuesta. La caracterización siguiente es la interpretación de ANKATech del modelo, no una referencia externa.

NIST propone una visión complementaria, adaptando los niveles de su Cybersecurity Framework a la agilidad criptográfica, desde prácticas parciales y no planificadas hasta un estado adaptativo en el que el riesgo criptográfico se monitorea, se mide y se reporta a los directivos ^[1]. Ambos modelos llevan a la misma conclusión: la madurez se mide por la capacidad de cambiar, no por los algoritmos que se usan actualmente.

10.2 Seis preguntas para el CISO

Las siguientes preguntas están diseñadas para revelar la duración de la brecha de respuesta de una organización antes de que lo haga un cambio real:

1. Si el mecanismo que protege sus datos más críticos se volviera inaceptable mañana, ¿cuántas aplicaciones tendría que modificar?
2. ¿Puede listar cada lugar donde se usa un algoritmo dado, distinguiendo operaciones como cifrar de descifrar y firmar de verificar?
3. ¿Puede detener el uso nuevo de un mecanismo sin detener el descifrado y la verificación de lo que ya protege?
4. ¿Quién decide qué mecanismo sirve a qué uso, y dónde se aplica esa decisión?
5. ¿Puede demostrar ante un auditor que un mecanismo no se ha usado para aplicar nueva protección desde una fecha determinada?
6. ¿Ha medido su brecha de respuesta para cada clase de sistema, y sabe qué sistemas definen su límite superior?

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.

ANKASecure© y la agilidad criptográfica

Los capítulos anteriores describen un modelo arquitectónico que puede implementarse de más de una forma. ANKASecure© es la implementación de ANKATech del Plano de Control Criptográfico, y la agilidad criptográfica es la primera propiedad que está diseñado para ofrecer.

11.1 Capacidades estables, mecanismos gobernados

Las aplicaciones invocan capacidades criptográficas estables, como cifrar, descifrar, firmar y verificar, sobre identificadores de clave estables. El mecanismo detrás de una capacidad lo gobierna la plataforma: una rotación de clave avanza a una nueva versión del material bajo el mismo identificador, y esa versión puede usar un algoritmo distinto dentro de la misma familia de propósito, sin cambios en las aplicaciones que la usan. Las claves compuestas híbridas que combinan algoritmos clásicos y poscuánticos, y los mecanismos poscuánticos basados en NIST FIPS 203, 204 y 205, pueden introducirse por la misma vía.

11.2 Tres políticas para el ciclo de vida completo

ANKASecure© expresa la agilidad criptográfica mediante tres tipos de política, definidos a nivel de despliegue y de tenant:

• Disponibilidad de algoritmos determina qué algoritmos pueden usarse, por lista explícita, familia, categoría (clásico, poscuántico o híbrido), nivel de seguridad, organismo de estándares obligatorio u operaciones permitidas. Un perfil solo híbrido, por ejemplo, implementa un requisito al estilo de la BSI como política y no como código.
• Rotación de algoritmos gobierna qué transiciones están permitidas, por ejemplo prohibiendo degradaciones de seguridad o un regreso de algoritmos poscuánticos a clásicos.
• Ciclo de vida de claves gobierna qué operaciones están permitidas en cada estado. El material reemplazado y retirado sigue disponible para descifrar y verificar mientras se deniegan el nuevo cifrado y la nueva firma; una clave revocada por deprecación de algoritmo mantiene legibles sus datos históricos, mientras que una clave revocada por compromiso queda sellada para toda operación.

En conjunto, estas políticas implementan la salida controlada descrita en el Capítulo 9: detener el uso nuevo de un mecanismo, preservar el procesamiento heredado donde la política lo permite y terminarlo de forma deliberada.

11.3 Modernización de los datos protegidos

Las operaciones dedicadas de recifrado y refirmado, incluidas operaciones en streaming para objetos de datos grandes, permiten trasladar la información protegida con un mecanismo antiguo a uno nuevo sin requerir que las aplicaciones que la crearon vuelvan a generar los datos. Esto es lo que convierte la última parte de la brecha de respuesta, la salida, de un programa en un proceso.

11.4 Evidencia del estado criptográfico

Cada operación se registra con su contexto, incluidos el algoritmo y la clave utilizados, lo que produce evidencia de qué mecanismos están aplicando protección, para qué usos y desde cuándo. Demostrar que un mecanismo ya no se usa para nueva protección se convierte en una consulta sobre registros gobernados en lugar de una auditoría de aplicaciones individuales.

11.5 Primeros pasos

1. Evaluación de la brecha de respuesta: identificar los mecanismos y sistemas que definirían la brecha de la organización si un mecanismo del que depende se volviera inaceptable.
2. Demostración y arquitectura de referencia: ANKASecure© cambiando un algoritmo, retirando un mecanismo y recifrando datos de extremo a extremo, sobre un caso análogo al de la propia organización.
3. Piloto acotado: un uso crítico gobernado por política, con las claves ancladas en el HSM o KMS existente de la organización.

Conclusión

La transición poscuántica es el mayor cambio criptográfico que la mayoría de las organizaciones emprenderá, y merece la urgencia que está recibiendo. Pero no es el último cambio criptográfico que enfrentarán. La evidencia de los últimos cuatro años, desde Rainbow y SIKE hasta HAWK, Classic McEliece y el oráculo de firma RSA, muestra que la evaluación de los mecanismos criptográficos se mueve por muchas razones, según su propio calendario y, a veces, en cuestión de meses.

Para las empresas, el umbral decisivo no es si un mecanismo está roto, sino si sigue siendo aceptable para un uso dado, y la aceptabilidad puede retirarse antes de que exista cualquier ataque práctico. Lo que determina el riesgo cuando eso ocurre es la Brecha de Respuesta Criptográfica: cuánto tiempo sigue dependiendo la organización de un mecanismo después de que deja de ser aceptable. Esa brecha la fija la arquitectura. Una organización que completa una migración con algoritmos incrustados en cada aplicación ha cambiado su criptografía, pero ha conservado su brecha.

La agilidad criptográfica la cierra. Significa separar lo que las aplicaciones necesitan de los mecanismos que lo proveen, gobernar esos mecanismos como política, aplicar esa política donde se ejecuta la criptografía y gestionar la salida de la criptografía antigua con la misma deliberación que la adopción de la nueva.

La pregunta no es si la criptografía cambiará. Cambiará. La pregunta es cuánto de su empresa debe cambiar cuando lo haga.

Referencias

1. [1] NIST. Considerations for Achieving Crypto Agility: Strategies and Practices. Cybersecurity White Paper CSWP 39, diciembre de 2025, actualizado el 29 de junio de 2026. https\://doi.org/10.6028/NIST.CSWP.39-upd1
2. [2] NIST Computer Security Resource Center. Proyecto Crypto Agility. https\://csrc.nist.gov/projects/crypto-agility
3. [3] R. Housley. Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms. IETF RFC 7696 / BCP 201, noviembre de 2015. https\://www.rfc-editor.org/rfc/rfc7696
4. [4] E. Barker, A. Roginsky. Transitioning the Use of Cryptographic Algorithms and Key Lengths. NIST SP 800-131A Rev. 2, marzo de 2019. https\://doi.org/10.6028/NIST.SP.800-131Ar2
5. [5] NIST. Transition to Post-Quantum Cryptography Standards. NIST IR 8547, octubre de 2026. https\://doi.org/10.6028/NIST.IR.8547
6. [6] The White House. Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks, 22 de junio de 2026. https\://www.whitehouse.gov/wp-content/uploads/2026/06/eo-14412.pdf
7. [7] UK National Cyber Security Centre. Timelines for migration to post-quantum cryptography, marzo de 2025. https\://www.ncsc.gov.uk/guidance/pqc-migration-timelines
8. [8] NIS Cooperation Group. A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, junio de 2025.
9. [9] W. Beullens. Breaking Rainbow Takes a Weekend on a Laptop. CRYPTO 2022; IACR ePrint 2022/214. https\://eprint.iacr.org/2022/214
10. [10] W. Castryck, T. Decru. An efficient key recovery attack on SIDH. EUROCRYPT 2023; IACR ePrint 2022/975. https\://eprint.iacr.org/2022/975
11. [11] NIST. Nine candidates advance to third round of additional digital signatures for PQC, 14 de mayo de 2026, actualizado el 29 de julio de 2026. https\://www.nist.gov/news-events/news/2026/05/nine-candidates-advance-third-round-additional-digital-signatures-pqc
12. [12] Anthropic Frontier Red Team. Discovering cryptographic weaknesses with Claude, 28 de julio de 2026. https\://www.anthropic.com/news/discovering-cryptographic-weaknesses
13. [13] A. Ghoshal, Y. Ishai, A. Jain, N. Sun. Quasipolynomial Cryptanalysis of the McEliece Cryptosystem (or: PIR Meets McEliece). IACR ePrint 2026/1630, agosto de 2026. https\://eprint.iacr.org/2026/1630
14. [14] Bundesamt für Sicherheit in der Informationstechnik (BSI). Notes on recent developments concerning Classic McEliece, 29 de septiembre de 2026.
15. [15] ISO/IEC 18033-2:2006/Amd 2:2026. Information technology, Security techniques, Encryption algorithms, Part 2: Asymmetric ciphers, Amendment 2.
16. [16] NIST. Status Report on the Fourth Round of the NIST Post-Quantum Cryptography Standardization Process. NIST IR 8545, marzo de 2025. https\://doi.org/10.6028/NIST.IR.8545
17. [17] L. Shea, M. Haller, A. Suhl, N. Heninger, E. Thomé. Forging 1024-bit RSA signatures in nearly SNFS time. IACR ePrint 2026/2131, septiembre de 2026. https\://eprint.iacr.org/2026/2131
18. [18] B. Schneier. Full Disclosure and the Window of Exposure. Crypto-Gram, 15 de septiembre de 2000. https\://www.schneier.com/crypto-gram/archives/2000/0915.html
19. [19] N. Rameshan, G. Messmer. An Assessment Framework for Application-Level Cryptographic Agility. arXiv:2606.13425, 2026. https\://arxiv.org/abs/2606.13425
20. [20] A. Langley. Cryptographic Agility. ImperialViolet, 16 de mayo de 2016. https\://www.imperialviolet.org/2016/05/16/agility.html
21. [21] E. Barker. Recommendation for Key Management: Part 1, General. NIST SP 800-57 Part 1 Rev. 5, mayo de 2020. https\://doi.org/10.6028/NIST.SP.800-57pt1r5
22. [22] ANKATech Solutions INC. The Cryptographic Control Plane: Introducing CAPA, Crypto Agility Posture Architecture. Whitepaper V2, septiembre de 2026.
23. [23] ANKATech Solutions INC. Cryptographic Sovereignty in Third-Party Information Exchange. Whitepaper V3, 2026.

ANKATech Solutions INC. ANKASecure© es un producto de ANKATech Solutions INC. Este documento se proporciona con fines informativos y refleja el estado de las fuentes citadas a octubre de 2026.