Cloudflare Workers suma criptografía post-cuántica nativa

Cloudflare lleva la criptografía post-cuántica al runtime de Workers

Cloudflare convirtió a Workers en el primer runtime serverless de gran escala con ML-KEM y ML-DSA accesibles vía Web Crypto, sin que el equipo de desarrollo tenga que empaquetar su propia implementación. Hasta hoy, experimentar con criptografía post-cuántica en JavaScript significaba cargar librerías en WASM o reescribir primitivas a mano: un lastre que la mayoría de startups simplemente no se podía permitir.

El movimiento es relevante porque Workers es donde corre una parte creciente de APIs, gateways de autenticación y edge functions. Que el runtime exponga los algoritmos estandarizados por NIST en 2024 cambia la economía de la transición para cualquier founder que firme JWT, monte túneles cifrados o sirva tráfico OHTTP.

¿Qué anuncia Cloudflare exactamente?

El blog oficial publicado el 1 de octubre de 2026 confirma que Workers expone, a través del flag de compatibilidad webcrypto_modern_algorithms, los siguientes algoritmos:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

ML-KEM-768 y ML-KEM-1024 como mecanismo de encapsulación de claves.
ML-DSA-44, ML-DSA-65 y ML-DSA-87 para firmas digitales.
Nuevos métodos en SubtleCrypto: encapsulateBits(), decapsulateBits(), encapsulateKey(), decapsulateKey() y getPublicKey().
SubtleCrypto.supports() para que las librerías detecten disponibilidad antes de invocar.
Importación y exportación de claves en formato JWK para todos los algoritmos anteriores.

La implementación se apoya en BoringSSL, la misma biblioteca que ya usa el resto del stack criptográfico del runtime. Cloudflare aclara que ML-KEM-512 no está soportado porque la versión actual de BoringSSL no lo expone, y que la API sigue un draft del W3C Web Incubator Community Group, por lo que se mantiene opt-in hasta validar con autores de librerías.

ML-KEM y ML-DSA: qué resuelven en una línea cada uno

ML-KEM (antes conocido como Kyber, estandarizado como FIPS 203 en agosto de 2024) es un mecanismo de encapsulación de claves: dos partes obtienen un secreto compartido a partir de una clave pública. Sustituye, en protocolos como HPKE, los acuerdos de clave basados en Diffie-Hellman.
ML-DSA (antes Dilithium, FIPS 204) es el esquema de firma post-cuántica equivalente a Ed25519 o ECDSA: se genera un par de claves, se firman bytes, se verifican.

El detalle clave para founders: las claves y firmas de ML-DSA son sustancialmente más grandes que las de RSA o Ed25519, como recordatorio el post original. La ventaja es que ya no tienes que empaquetar bytes de criptografía en tu bundle de Workers — el runtime lo hace por ti.

El contexto regulatorio: la cuenta atrás ya empezó

Cloudflare no está moviéndose en el vacío. NIST finalizó los tres primeros estándares post-cuánticos —ML-KEM, ML-DSA y SLH-DSA— en agosto de 2024, y propuso retirar los algoritmos cuántica-vulnerable de sus estándares hacia 2035, con deprecación efectiva de RSA y ECC en 2030, según recoge CIO.com.

El ritmo de adopción empresarial lo expuso el Director Arvind, según publicó MeriTalk el 25 de septiembre: Apple, Google, IBM y Amazon ya implementan los estándares NIST a escala, Google usa ML-KEM directamente en Chrome, y 60 empresas participan en el National Cybersecurity Center of Excellence. Google Cloud apunta a estar completamente listo para post-cuántica en 2029, mismo horizonte que Cloudflare según el análisis de SDxCentral.

La cifra que mejor dimensiona el momentum: su red ya protege alrededor de 45 mil millones de conexiones por día entre Cloudflare y servidores de origen vía Automatic Key Exchange, una métrica reportada por el mismo análisis sectorial.

En el mundo Java, Oracle интегрó ML-KEM y ML-DSA en JDK 24 en marzo de 2025, y el 15 de septiembre de 2026 lanzó JDK 27 con TLS 1.3 híbrido post-cuántico usando X25519MLKEM768 como primer grupo de intercambio de claves, según FinanceFeeds. Es decir: el ecosistema de runtimes — Workers, JVM, navegadores — se está moviendo en la misma dirección.

Qué cambia para founders que construyen sobre Workers

Para una startup típica que hoy firma JWT, hace llamadas firmadas entre microservicios o expone APIs en el edge, las implicaciones son tres:

JWT firmados con ML-DSA ya son viables en el edge. El propio post muestra un ejemplo usando la popular librería panva/jose: el código de aplicación no cambia, la librería delega la firma al runtime. Si tu roadmap 2027 incluye "quantum-safe auth", este es el punto de partida más directo.
HPKE y OHTTP pueden subir a KEM post-cuánticos. El ejemplo del blog usa panva/hpke con HPKE.KEM_ML_KEM_768. Si construyes VPNs ligeras, proxies o relays de Oblivious HTTP, ya no hace falta que cada implementación cargue su propia criptografía.
El handshake TLS deja de ser tu cuello de botella principal. AWS midió entre 80 y 150 microsegundos adicionales por handshake TLS al habilitar hybrid ML-KEM, según SDxCentral. Es un coste conocido y manejable, no un argumento para posponer la transición.

Acciones concretas que puedes tomar esta semana

Activa el flag en un proyecto de prueba. Añade "compatibility_flags": ["webcrypto_modern_algorithms"] a tu wrangler.jsonc y ejecuta el snippet de crypto.subtle.generateKey("ML-DSA-44", ...) del blog. Verás el overhead real de tamaño de firma en tus propios logs.
Audita dónde firmas o encapsulas hoy. Lista cada llamada a auth2.sign, auth2.verify, generación de JWT y túneles HPKE/OHTTP. Si dependes de una librería que embebe su propia implementación, abre un issue pidiendo que use SubtleCrypto.supports() antes de hacer fallback.
Mide el impacto en tamaño y latencia. Firma un payload típico con ML-DSA-44 y compara contra Ed256iyen o RS256. Documenta el delta en KB transmitidos y ms añadidos: te anticipa lo que verás cuando AWS, GCP o tu CDN migren a TLS híbrido.
No bloquees tu roadmap esperando el estándar final. La API está en draft y es opt-in. Es exactamente el tipo de integración que conviene prototipar antes, no cuando tu proveedor te obligue.

Lo que Cloudflare aún no incluye (y merece la pena seguir)

El post es claro en lo que queda fuera de esta primera entrega: SHA-3, cSHAKE, TurboSHAKE, ChaCha20-Poly1305 y una API de HPKE de alto nivel están en la propuesta original de panva, pero no se incluyeron para mantener el scope revisable. Cloudflare también deja abierta la pregunta de si el flag debería volverse default, lo que mantiene la puerta abierta a que autores de librerías reporten fricciones antes de que se congele la API.