Cloudflare usa IA para su migración post-cuántica hacia 2029

Por qué Cloudflare se puso 2029 como fecha límite

El 29 de septiembre, Cloudflare publicó los detalles de CryptoLabe, una herramienta interna basada en modelos de IA que mapea dónde y cómo se usa criptografía en su código. Es la pieza que faltaba para explicar cómo piensa cumplir su compromiso de ser 100% post-cuántica para 2029, en una red que, según datos de la propia compañía publicados el 8 de septiembre, ya protege alrededor de 45.000 millones de conexiones TLS 1.3 al día con algoritmos post-cuánticos híbridos.

El reloj no es decorativo. La amenaza ya está documentada como harvest-now, decrypt-later: un atacante graba tráfico cifrado hoy y espera a tener un ordenador cuántico para descifrarlo. Por eso, según SDxCentral, tanto Google Cloud como Cloudflare se pusieron 2029 como meta de preparación total, mientras el NIST de EE. UU. —que finalizó sus primeros tres estándares PQC en agosto de 2024 (ML-KEM, ML-DSA y SLH-DSA)— pidió retirar los algoritmos vulnerables de sus estándares hacia 2035 y empezar a migrar ya.

Cloudflare describe su enfoque como maximalist: «PQ everything». Como proveedor de infraestructura, no quiere que un cliente de su plataforma quede expuesto por usar un servicio interno sin migrar.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Qué es CryptoLabe y por qué necesitaban IA

CryptoLabe —bautizada por el astrolabio del navegante portugués— es una herramienta interna, no se venderá a clientes, pero Cloudflare publicó los prompts para que otros equipos la repliquen. El problema que ataca es clásico en migraciones a gran escala: la criptografía rara vez se anuncia en el código.

La nota original describe tres retos:

El código está repartido en muchos repositorios.
La criptografía se esconde en librerías compartidas que el repo importa pero quizá no llama, en defaults de protocolos (un listener TLS 1.3 que negocia X25519 clásico en vez de X25519MLKEM768), y en archivos de configuración separados del código que los usa.
Hacer grep por nombres como «RSA» o «X25519» sobrecuenta (encuentra criptografía en código muerto) y subcuenta (se pierde los defaults y dependencias indirectas). Y lo más importante: no te dice cómo se está usando esa criptografía.

Ahí entra la IA. Un modelo puede seguir evidencia entre archivos, devolver análisis estructurado y, sobre todo, explicar el rol de cada uso: una firma ECDSA clásica puede ser parte de un JWT, de IPsec, de TLS o de SSH, y cada uno requiere una migración distinta.

Cómo encuentra CryptoLabe la criptografía oculta en el código

El pipeline tiene dos etapas, según explica Cloudflare:

Discovery (mapeo): escanea el repositorio en busca de criptografía en código fuente, configuración, manifests, lockfiles, scripts, tests y documentación. Cubre key agreement, firmas, cifrado asimétrico, PKI, tokens, credenciales e integraciones con HSM. Produce raw observations.
Deep analysis (verificación): por cada observación, re-checa contra el código, investiga cómo se usa esa operación en runtime, qué rol cumple el repo y de qué partes internas o externas depende. Si hace falta, inspecciona código en otros repos para cerrar el caso. Antes de cerrar, da otra pasada buscando evidencia contradictoria: overrides de configuración, código solo para tests o suposiciones incorrectas sobre el comportamiento en runtime.

Luego asigna una clasificación: classical encryption (ECDHE, RSA key agreement, HPKE), classical signature (RSA/ECDSA en certificados o handshakes), classical token (JWT RS256/ES256, con reemplazo PQ definido en RFC 9964), PQ-ready hybrid key exchange (X25519MLKEM768 en TLS 1.3) o PQ-ready (otros usos como ML-DSA). Si la evidencia no alcanza, devuelve etiquetas explícitas —More evidence needed, External dependency, Unknown— en vez de inventar.

Cada hallazgo termina en un informe con dos audiencias: product managers, que necesitan entender el impacto para su producto, e ingenieros, que necesitan detalle suficiente para ejecutar el cambio.

Qué infraestructura usa Cloudflare para correr CryptoLabe

Cloudflare construyó CryptoLabe sobre su propia Developer Platform, un detalle relevante porque muestra cómo se puede orquestar IA a escala sin construir un cluster desde cero:

Dos Cloudflare Workers: uno es el scanner que corre los escaneos; el otro es el inventory que sirve el dashboard, expone la API y guarda todo en una base D1. Se comunican vía Service Bindings.
Un Durable Object por repositorio actúa de coordinador persistente del escaneo, con una bounded queue delante para limitar cuántos corren a la vez. El coordinador delega el procesamiento pesado a Cloudflare Workflows, que persisten progreso y reintentan pasos fallidos en cuatro etapas: discovery, deep analysis, merge y publish.
El código del repo se descarga una sola vez al inicio del escaneo, en un commit exacto, y se guarda como snapshot inmutable en R2. Cada Workflow restaura ese snapshot en un Sandbox efímero y la IA trabaja con él a través de herramientas read-only.
Para el modelo, el tráfico pasa por AI Gateway, que enruta hacia modelos open-weight hospedados en Workers AI — la opción más barata para escalar. Cuando los escaneos empezaron a golpear HTTP 429 (rate limit), un único Durable Object global pacea todas las llamadas a modelos en todos los escaneos, incluido los reintentos, y aplica un cooldown compartido.

La lección operativa: la IA a escala se sostiene con orquestación determinista (Workers, Durable Objects, Workflows) alrededor de los llamados al modelo, no con esperanza y buena memoria.

Qué casos difíciles aparecen en una migración post-cuántica

CryptoLabe también sirve para algo que suele hundir las migraciones: prerrequisitos y casos duros tempranos. Un prerrequisito típico es «estamos bloqueados para migrar los JWT a post-cuántico»: existe el estándar (RFC 9964), pero si tu librería no valida JWTs PQ o tu emisor no los emite, no podés pedirles a todos los equipos que migren a la vez.

Los hard cases — usos sin soporte ecosistema claro— requieren otro prompt aparte. Cloudflare busca protocolos criptográficos custom, criptografía integrada en hardware, firmas ciegas, protocolos sin estándar PQ y dependencias externas sin soporte. Encontraron, por ejemplo, un certificado transportado en una cabecera HTTP: como los certificados PQ son más grandes que los clásicos, cualquier asunción de tamaño en el header, el middleware o la aplicación puede romper el sistema al cambiar el algoritmo de firma.

El contexto del sector ayuda a dimensionar el esfuerzo. Según Cloudflare, alrededor del 12,8% de los orígenes en su red ya soportan acuerdo de claves PQ en TLS 1.3, frente al 0,5% en 2023. AWS, citado por SDxCentral, midió entre 80 y 150 microsegundos extra por handshake TLS al usar ML-KEM híbrido. En Europa, según Blockonomi, los estados miembros de la UE deben comenzar la migración antes de fin de 2026 y completar la de sistemas críticos antes de 2030.

La conclusión de Cloudflare es incómoda pero clara: ningún escaneo encuentra todo. Por eso usan varios enfoques y siempre revisan los hallazgos con los ingenieros que mantienen cada repo.

Qué significa esto para tu startup

No necesitás replicar CryptoLabe para empezar. La propia Cloudflare advierte que un inventario criptográfico exhaustivo no es prerrequisito para actuar. La secuencia práctica que recomiendan —y que aplica a cualquier equipo chico— es:

Activá cifrado PQ en lo que ya pasa por Cloudflare, Cloudflare One o un CDN similar. El cifrado post-cuántico en tránsito ya está disponible sin costo extra para sitios detrás de Cloudflare y para tráfico privado en Cloudflare One. Es un control compensatorio mientras auditas el resto.
Empezá por un repositorio crítico, no por todos. Elegí un sistema que maneje datos sensibles o de larga vida, que autentique usuarios o software, o que esté expuesto a Internet. Corré descubrimiento de criptografía sobre ese repo, validá los hallazgos con el equipo que lo mantiene y decidí qué upgrade se puede hacer ahora y qué está bloqueado por un prerrequisito.
Preguntale a tus vendors qué estándares NIST soportan, en qué plazos y quién es responsable de migrar certificados, librerías y hardware. No aceptes un sello «quantum-safe» sin ver la ruta completa. Y verificá con herramientas como Cloudflare Radar si tu origen ya negocia TLS post-cuántico.

El mensaje de fondo para founders: la migración post-cuántica ya dejó de ser una conversación académica. Las decisiones que tomes sobre TLS, autenticación y dependencias criptográficas en los próximos meses determinan si tu producto queda expuesto a harvest-now, decrypt-later o si, como Cloudflare, llegás a 2029 con el mapa listo.