Hagamos un ejercicio incómodo. Pregúntele hoy a su equipo dónde usa la organización RSA de 2048 bits: con qué relleno, para firmar qué, en qué aplicaciones, con llaves generadas por quién, custodiadas dónde y vigentes hasta cuándo. En la mayoría de las entidades la respuesta tarda semanas, llega de tres fuentes que no coinciden entre sí y termina en una hoja de cálculo que envejece el mismo día en que se entrega.
Eso no era grave mientras la criptografía se pudiera dejar quieta. Hoy sí lo es, porque por primera vez en treinta años la criptografía de llave pública que sostiene a la banca tiene fecha de retiro escrita en un estándar, y porque el adversario no necesita esperar a esa fecha para empezar a atacar.
Ese inventario tiene nombre: CBOM, Cryptography Bill of Materials.
El riesgo cuántico, con precisión
Conviene ser exacto, porque la conversación pública mezcla dos problemas de naturaleza distinta.
El algoritmo de Shor resuelve en tiempo polinomial la factorización de enteros y el logaritmo discreto, incluido el logaritmo discreto sobre curvas elípticas. Eso no debilita a RSA, a Diffie-Hellman, a ECDH, a ECDSA y a EdDSA: los elimina como base de seguridad. Y con ellos cae todo lo que se construyó encima: el intercambio de llaves de TLS, la firma de los certificados de cualquier PKI, la firma de código y de firmware, los tokens de sesión firmados con RS256 o ES256, la autenticación mutua entre sistemas y las ceremonias de llaves de un módulo de seguridad de hardware.
Aumentar el tamaño de llave no cambia la categoría del problema. El costo del ataque de Shor crece de manera polinomial con el tamaño del módulo, así que pasar de RSA-2048 a RSA-4096 multiplica el trabajo del atacante cuántico por una constante modesta mientras encarece cada operación legítima. Usar P-384 en lugar de P-256 tampoco convierte a ECDSA en resistente. No hay parámetro que salve a estas familias.
Y hay un detalle que sorprende a muchos comités técnicos: la curva elíptica cae antes que RSA, no después. Su mejor seguridad frente a un atacante clásico llevó a la industria a usar llaves de 256 bits en lugar de 2048, y al algoritmo de Shor le importa sobre todo el tamaño de la llave. Las estimaciones más recientes sobre curvas de 256 bits hablan de minutos de ejecución; las de RSA-2048, de días o semanas.
El algoritmo de Grover es otra cosa. Ofrece una aceleración cuadrática sobre búsquedas genéricas, de forma simplificada:
Por eso AES-256 conserva un margen amplio. Además, Grover no se paraleliza bien: repartir la búsqueda entre muchas máquinas degrada la ventaja, de modo que su efecto práctico es menor que el que sugiere la fórmula. El caso que sí pierde margen es AES-128. Con las funciones de resumen ocurre algo similar: SHA-256 sigue siendo razonable, y CNSA 2.0 exige SHA-384 por prudencia y no porque SHA-256 esté roto.
| Tecnología | Situación frente a un adversario cuántico |
|---|---|
| RSA y Diffie-Hellman | Se rompen con Shor. Sin parámetro de rescate |
| ECDH, ECDSA, EdDSA | Se rompen con Shor, y antes que RSA |
| AES-128 | Margen reducido por Grover |
| AES-256 | Margen fuerte |
| SHA-256 y SHA-384 | Impacto limitado. CNSA 2.0 exige SHA-384 |
| ML-KEM, FIPS 203 | Diseñado para seguridad post-cuántica |
| ML-DSA, FIPS 204 | Diseñado para seguridad post-cuántica |
| SLH-DSA, FIPS 205 | Diseñado para seguridad post-cuántica |
El NIST publicó esos tres estándares el 13 de agosto de 2024. En marzo de 2025 seleccionó además HQC, un mecanismo de encapsulamiento de llaves basado en códigos correctores de errores y no en retículos, para no depender de una sola familia de supuestos matemáticos. Su estándar se espera para 2027.
Cuánto se acortó el plazo
Conviene decirlo antes que nada: no se ha roto ninguna llave. Ningún computador cuántico ha factorizado un RSA de 2048 bits ni ha resuelto un logaritmo discreto sobre una curva de 256 bits, y las máquinas que existen hoy están muy lejos de poder hacerlo. Lo que se mueve, y rápido, no es el hardware sino la estimación de cuánto hardware haría falta.
En 2019, Craig Gidney y Martin Ekerå estimaron que factorizar una llave RSA de 2048 bits tomaría ocho horas con 20 millones de qubits físicos ruidosos. En mayo de 2025, Gidney, de Google Quantum AI, rebajó esa cifra a menos de un millón de qubits, con un tiempo de ejecución de menos de una semana. Esa comparación es la única limpia del conjunto, porque mantiene los mismos supuestos de hardware que la de 2019: misma tasa de error por compuerta, misma conectividad, mismo código de superficie. Lo que cambió fue la matemática, no la máquina.
Para romper RSA-2048. Mismo hardware supuesto en ambas estimaciones: cambió la matemática, no la máquina.
Después llegaron tres resultados más, todos en preimpresiones sobre arquitecturas que nadie ha construido. En febrero de 2026, Iceberg Quantum presentó la arquitectura Pinnacle, que reemplaza los códigos de superficie por códigos qLDPC y sitúa el ataque a RSA-2048 por debajo de 100.000 qubits físicos. El 30 de marzo de 2026, Google Quantum AI, junto con la Fundación Ethereum y la Universidad de Stanford, publicó estimaciones para el logaritmo discreto sobre curvas de 256 bits: menos de 1.200 qubits lógicos y 90 millones de compuertas Toffoli, que sobre una arquitectura superconductora se traducen en menos de 500.000 qubits físicos y unos nueve minutos de ejecución. En esos mismos días, un equipo de Oratomic, Caltech y la Universidad de California en Berkeley describió arquitecturas de átomos neutros con cerca de 26.000 qubits para esa misma curva en unos diez días, y alrededor de 102.000 qubits para RSA-2048 en unos tres meses.
Esas cifras no forman una sola curva y no deben presentarse como tal: cada una cambia el código corrector, el modelo de conectividad y el tiempo de ejecución, así que no son comparables entre sí. Ninguna máquina actual se acerca a esos tamaños y RSA-2048 no está roto hoy. Lo que sí muestran, y esto es lo que debería preocupar a un comité de riesgos, es que el costo estimado del ataque puede caer varios órdenes de magnitud por avances matemáticos, antes de que se añada un solo qubit a una máquina real.
El mercado ya está reaccionando a esa pendiente. El 25 de marzo de 2026, Google fijó 2029 como el año en que terminará de migrar su propia infraestructura a criptografía post-cuántica, muy por delante de los plazos regulatorios.
Las fechas ya no las pone la física
El NIST IR 8547, todavía en versión preliminar, plantea que los algoritmos de llave pública con 112 bits de seguridad, entre ellos RSA-2048 y ECDSA sobre P-256, queden deprecados después de 2030 y prohibidos después de 2035. La NSA, en su marco CNSA 2.0, fijó el 1 de enero de 2027 como la fecha desde la cual toda adquisición nueva para sistemas de seguridad nacional debe soportar los algoritmos post-cuánticos, con uso exclusivo en firma de software y firmware en 2030 y en navegadores, servidores y nube en 2033.
En Europa, la hoja de ruta coordinada publicada en junio de 2025 pide planes nacionales de transición antes de terminar 2026, los casos de uso de alto riesgo migrados en 2030 y la transición completa en 2035. Francia fue más lejos: la ANSSI anunció que desde 2027 dejará de certificar productos de seguridad que no incorporen criptografía post-cuántica, y que desde 2030 las compras deberían limitarse a productos resistentes al ataque cuántico. Perder esa certificación equivale a perder el acceso al mercado público francés. En el sector financiero, el Grupo de Expertos en Ciberseguridad del G7 publicó en enero de 2026 una hoja de ruta que sitúa la evaluación de riesgo y la planeación en 2026.
Colombia no está por fuera de esa conversación. En 2026 se conformó la primera Mesa Sectorial de Criptografía Poscuántica, con Gobierno, academia, sector financiero e infraestructura crítica. El Observatorio Quantum Safe de la Universidad de los Andes, del que Cyte es patrocinador tecnológico, mide en vivo cuántos servidores siguen expuestos: el 57,2% de los analizados ya son vulnerables. Cuando la Superintendencia Financiera traslade a una circular lo que ya está en los estándares internacionales, cumplir será una carrera contra el reloj.
Por qué el plazo real ya venció para algunos datos
El ataque que hoy está en curso se llama harvest now, decrypt later: robar ahora, descifrar después. Un adversario intercepta tráfico cifrado, lo almacena en discos que cuestan centavos por gigabyte y espera la capacidad de cómputo que le falta. No necesita forzar nada. La información bancaria, las historias clínicas, la propiedad intelectual, los contratos de Estado y las llaves privadas de larga vida son objetivos rentables precisamente porque deben seguir siendo confidenciales por décadas.
La forma de saber si usted ya está tarde es la desigualdad de Mosca. Llame X a los años durante los cuales un dato debe seguir siendo confidencial, Y a los años que le tomará migrar su criptografía y Z a los años que faltan para que exista un computador cuántico capaz del ataque:
Haga la cuenta con un crédito hipotecario a veinte años, una migración realista de tres años en una entidad mediana y una estimación de Q-Day alrededor de 2032. La desigualdad se cumple con holgura. Ese dato, cifrado hoy con intercambio de llaves clásico, ya se puede considerar expuesto. Y note cuál es la variable que usted controla: no es Z, es Y, y Y depende por completo de qué tan rápido pueda encontrar y reemplazar su propia criptografía.
No se migra lo que no se ve
Aquí es donde casi todos los programas post-cuánticos se detienen antes de empezar. La organización sabe que debe reemplazar RSA y curva elíptica, pero no sabe dónde están. Administra certificados en hojas de cálculo, desconoce qué librerías criptográficas quedaron compiladas dentro de su propio código y descubre un algoritmo débil cuando lo encuentra un auditor o cuando un certificado vencido tumba un servicio.
Un CBOM es el inventario estructurado y legible por máquina de todos los activos criptográficos de una organización: algoritmos, protocolos, certificados y material de llaves, junto con su ubicación, su configuración, sus dependencias y el sistema que los usa.
El estándar CycloneDX incorpora el CBOM desde su versión 1.6, publicada en abril de 2024, mediante componentes de tipo cryptographic-asset con un objeto cryptoProperties que clasifica cada activo en cuatro tipos: algorithm, certificate, protocol y related-crypto-material. Para un algoritmo permite declarar la primitiva, el conjunto de parámetros, la curva, el modo, el relleno, las funciones criptográficas que cumple, el entorno de ejecución, el nivel de certificación y el nivel de seguridad clásico y cuántico:
{
"type": "cryptographic-asset",
"name": "ECDSA-P256-SHA256",
"cryptoProperties": {
"assetType": "algorithm",
"algorithmProperties": {
"primitive": "signature",
"parameterSetIdentifier": "P-256",
"curve": "secp256r1",
"executionEnvironment": "hardware",
"implementationPlatform": "x86_64",
"certificationLevel": ["fips140-2-l3"],
"cryptoFunctions": ["sign", "verify"],
"classicalSecurityLevel": 128,
"nistQuantumSecurityLevel": 0
},
"oid": "1.2.840.10045.4.3.2"
}
}
Ese último campo es la razón por la cual el CBOM es una herramienta post-cuántica y no solo un inventario ordenado. El valor nistQuantumSecurityLevel corresponde a las categorías de seguridad definidas por el NIST en su proceso de estandarización y vale cero cuando el activo no alcanza ninguna. Un cero ahí significa, de manera explícita y consultable por máquina, que ese activo no ofrece resistencia alguna frente a un adversario cuántico. Priorizar la migración deja de ser una discusión de opiniones y pasa a ser una consulta sobre un inventario.
De ahí se derivan tres consecuencias prácticas.
La consulta en minutos
Cuando aparezca una debilidad en una curva, en una librería o en un modo de operación, la pregunta "dónde lo estoy usando" se resuelve con una consulta y no con un censo de tres meses.
El grafo de dependencias
CycloneDX permite enlazar cada activo criptográfico con el componente de software que lo invoca y con el sistema que lo expone. Así se descubre que un mismo certificado sostiene siete servicios, o que la llave de firma de un riel de pagos vive en un HSM cuyo firmware todavía no soporta ML-DSA.
Integrado al ciclo de desarrollo
Si se genera en cada compilación, junto con el SBOM, deja de ser una foto y pasa a ser un control: se puede bloquear una entrega que introduzca un algoritmo prohibido por política, igual que hoy se bloquea una dependencia con vulnerabilidad crítica.
CycloneDX avanzó en esa dirección con el registro de criptografía que incorporó en su versión 1.7, el cual normaliza los nombres de familias de algoritmos y de curvas para que dos inventarios sean comparables entre sí. Herramientas como CBOMkit e IBM Quantum Safe Explorer ya producen inventarios en ese formato a partir de código y dependencias, y el NIST documenta herramientas de descubrimiento para servicios de red como TLS y SSH.
Cómo se construye un CBOM que de verdad sirva
El descubrimiento no tiene una sola fuente, porque la criptografía no vive en un solo lugar. Un inventario serio se arma cruzando por lo menos seis frentes.
Código y dependencias
Se buscan las invocaciones a las interfaces criptográficas del lenguaje, a OpenSSL, a Bouncy Castle o a PKCS#11, y se revisan las dependencias transitivas, donde suele esconderse el algoritmo que nadie eligió conscientemente.
Binarios y firmware
Se trabaja cuando no hay código fuente, que es la norma en sistemas heredados, en componentes comprados hace quince años y en dispositivos de campo.
Red y servicios
Se escanean versiones de TLS, suites de cifrado, llaves de host SSH, túneles VPN y conexiones a bases de datos, que es donde aparecen los TLS 1.0 y las llaves RSA de 1024 bits que todavía sobreviven en producción.
Certificados y PKI
Se consolidan las autoridades internas, los certificados autofirmados, las cadenas de confianza y los vencimientos, lo cual resuelve además un problema operativo inmediato: un certificado vencido tumba un servicio crítico sin aviso.
Llaves y módulos de seguridad
Se inventaría el material criptográfico propiamente dicho: llaves simétricas, llaves privadas, tokens, su estado, su fecha de activación y su ubicación física o lógica.
Terceros y nube
Se documenta lo que no se controla: el proveedor de procesamiento, el servicio administrado y el corresponsal que exigirá canales post-cuánticos antes que su propio regulador.
Conviene decir también lo que un CBOM no ve con facilidad, porque un inventario que se presenta como completo cuando no lo está es peor que no tenerlo. La criptografía negociada en tiempo de ejecución, la que se delega a aceleración por hardware, la que vive dentro de un dispositivo cerrado y la que ejecuta un tercero en su propia infraestructura solo se capturan de forma indirecta. Por eso el esquema admite un nivel de confianza por hallazgo y el nombre del escáner que lo produjo, y por eso el inventario debe reportar su porcentaje de cobertura.
Un CBOM honesto vale más que uno completo en apariencia.
Lo que además aparece cuando se enciende la luz
El descubrimiento tiene un efecto secundario que suele sorprender al comité: encuentra criptografía que ya está rota hoy, sin necesidad de ningún computador cuántico. No es la excepción, es el patrón. En la práctica, la criptografía falla mucho más por cómo se implementa que por la matemática que la sostiene, y esa clase de hallazgo aparece en casi todos los inventarios.
El caso más didáctico es AES-256 en modo ECB. AES-256 es un algoritmo simétrico excelente, pero en ECB cada bloque de 16 bytes se cifra de forma independiente y sin integridad, así que un mismo texto claro produce siempre el mismo bloque cifrado. Con una cookie de sesión de estructura email=...&uid=10&role=user, el atacante alinea los límites de bloque a su conveniencia, construye un segundo perfil donde aísla la palabra admin completada con relleno PKCS#7 válido, recorta los bloques de la primera cookie, pega el bloque de la segunda y obtiene una sesión de administrador:
descifra → email=AAAAAAAAAA&uid=10&role=admin
No conoció la llave, no rompió AES-256 y no descifró un solo bloque. Aprovechó una propiedad del modo y la ausencia de integridad.
El mismo patrón se repite con otras piezas. RSA de 2048 bits con relleno PKCS#1 versión 1.5 para transporte de llaves sigue siendo vulnerable a ataques de oráculo de relleno descritos por Bleichenbacher desde 1998 y revividos en 2017 bajo el nombre ROBOT, mientras que con OAEP el riesgo desaparece. AES-GCM con nonce aleatorio de 96 bits pierde la confidencialidad de un par de mensajes y entrega la subllave de autenticación cuando el nonce se repite, algo que deja de ser improbable en servicios de altísimo volumen bajo una misma llave.
De ahí se desprende la regla de oro del inventario: registrar el nombre del algoritmo no informa casi nada. Un CBOM debe registrar el modo, el relleno, la integridad, el origen de la llave, el uso y la ubicación exacta. Con eso, dos hallazgos con el mismo nombre terminan en extremos opuestos de la lista de prioridades.
De inventario a prioridad
El objetivo no es encontrar la palabra RSA. Es responder, para cada hallazgo: qué algoritmo es, en qué variante, con qué parámetros, dónde está, qué información protege, cuánto tiempo debe seguir protegiéndola, qué sistemas dependen de él y qué tan difícil sería reemplazarlo.
AES-256-GCM, nonce aleatorio, volumen moderado
algoritmo fuerte, uso adecuado
Prioridad bajaAES-256-ECB, sin integridad, cookie de autenticación
algoritmo fuerte, implementación peligrosa
Prioridad alta · riesgo vigente hoyECDH P-256, canal con datos de vida útil de 15 años
correcto frente a un atacante clásico
vulnerable a Shor, dato ya expuesto por robo diferido
Prioridad alta para migraciónEse ordenamiento es el producto real del inventario. Sin él, la migración empieza por donde es más fácil y no por donde duele.
Criptoagilidad: lo que de verdad cambia al migrar
Migrar no es reemplazar una cadena de texto en un archivo de configuración. Los algoritmos post-cuánticos tienen otras dimensiones y eso golpea a los protocolos. Una llave pública de X25519 ocupa 32 bytes. Una de ML-KEM-768 ocupa 1.184 bytes y su texto cifrado 1.088. Una firma ECDSA sobre P-256 ocupa 64 bytes; una de ML-DSA-65 ocupa 3.309 bytes, con una llave pública de 1.952; una de SLH-DSA en su perfil más compacto arranca cerca de 7.900 bytes. Medido sobre certificados reales, un certificado autofirmado con Ed25519 pesa unos 326 bytes y su equivalente con ML-DSA-65 supera los 5.500.
| Elemento | Clásico | Post-cuántico |
|---|---|---|
| Llave pública (KEM) | X25519 — 32 bytes | ML-KEM-768 — 1.184 bytes (+ 1.088 de texto cifrado) |
| Firma | ECDSA P-256 — 64 bytes | ML-DSA-65 — 3.309 bytes (llave pública: 1.952 bytes) |
| Firma compacta | — | SLH-DSA, perfil compacto — desde ~7.900 bytes |
| Certificado autofirmado | Ed25519 — ~326 bytes | ML-DSA-65 — más de 5.500 bytes |
Las consecuencias son concretas: las cadenas de certificados crecen decenas de kilobytes, el saludo inicial de TLS deja de caber donde antes cabía, los límites de amplificación de QUIC se vuelven relevantes, las tarjetas inteligentes y los tokens con memoria limitada se quedan cortos, los módulos de seguridad de hardware necesitan versiones de firmware que soporten los nuevos algoritmos y los formatos con campos de tamaño fijo simplemente no aceptan la firma.
Por eso la transición es híbrida. En intercambio de llaves ya es una realidad desplegada y no un plan: la combinación de X25519 con ML-KEM-768 es el modo predeterminado de Chrome desde su versión 131 y de Firefox desde la 132, y en abril de 2026 ya cubría más de dos tercios del tráfico TLS generado por personas hacia la red de Cloudflare. El esquema protege contra el robo diferido incluso si uno de los dos componentes falla. En firma la historia es más lenta, porque la firma depende de la confianza de terceros: no sirve firmar con ML-DSA si la contraparte no puede verificar.
La criptoagilidad es la capacidad de cambiar algoritmos y parámetros sin tumbar la operación. En la práctica significa que el algoritmo sea configuración y no código, que las llaves lleven identificador de versión, que exista negociación entre las partes y que la rotación se pueda hacer sin ventana de indisponibilidad. Es una propiedad de arquitectura y se diseña antes de necesitarla.
El CBOM no es un archivo de Excel anual
Es vivo, automatizado e integrado a la gestión de activos, de riesgos y de cambios. Se actualiza con cada despliegue y con cada escaneo. Y responde en minutos la pregunta que ninguna entidad quiere hacerse en medio de un incidente: si cae este algoritmo, ¿dónde lo estoy usando?
La pregunta que define hoy la madurez criptográfica de una organización ya no es "qué algoritmo usamos". Es esta otra: qué criptografía tenemos, cómo está implementada, qué riesgo tiene hoy, qué riesgo tendrá frente a un adversario cuántico y qué tan preparados estamos para reemplazarla.
En Cyte llevamos treinta años cifrando información crítica de bancos, gobiernos y empresas, y varios años desplegando criptografía post-cuántica en producción, incluso en entornos COBOL, AS/400 y OT. Nuestra criptografía protege el 95% de las transferencias interbancarias de Colombia. Notyfind construye y mantiene el CBOM de la organización, escanea red, nube y repositorios de código, alerta antes de que un certificado venza y entrega el inventario en el formato que auditores y reguladores van a exigir.
Si quiere una primera medición de su exposición, la calculadora de riesgo cuántico de cyte.co la entrega en cinco minutos con un cronograma de preparación según su nivel de riesgo. Y si quiere construir la hoja de ruta con sus pares del sector, ese es el trabajo de Quantum Mission, el encuentro que convocamos junto con EY para directivos de tecnología, seguridad, riesgo y cumplimiento.
¿Quiere saber qué tan expuesta está hoy su organización? Calcúlelo en cinco minutos y reciba un cronograma de preparación según su nivel de riesgo.
Calcular riesgo cuántico