Cloudflare añadió al entorno Cloudflare Workers compatibilidad opcional con los algoritmos de cifrado resistentes a la computación cuántica ML-KEM y ML-DSA dentro de la interfaz Web Crypto. El cambio permite a los desarrolladores probar alternativas modernas para el intercambio de claves y las firmas digitales utilizando interfaces nativas en el entorno de ejecución, en lugar de incluir implementaciones independientes en JavaScript o WebAssembly.
La compatibilidad está disponible actualmente mediante la etiqueta de compatibilidad webcrypto_modern_algorithms, porque la interfaz de algoritmos modernos todavía se basa en un borrador sujeto a cambios. La primera versión admite ML-KEM-768 para el encapsulamiento de claves y ML-DSA-44 para las firmas, y también proporciona ML-KEM-1024, ML-DSA-65 y ML-DSA-87. ML-KEM-512 no es compatible porque la versión de BoringSSL utilizada en Workers no lo ofrece.
¿Qué proporciona la nueva interfaz?
La incorporación incluye las operaciones encapsulateBits(), decapsulateBits(), encapsulateKey() y decapsulateKey(), además de getPublicKey(), SubtleCrypto.supports() y la importación y exportación de claves JWK para estos algoritmos. La interfaz de comprobación de compatibilidad permite a las bibliotecas evitar asumir que los algoritmos están disponibles en todos los entornos JavaScript, especialmente al ejecutar código mediante Workers, Node.js, Deno y los navegadores.
ML-KEM no implementa por sí solo el cifrado completo; produce material de clave compartida que protocolos como Hybrid Public Key Encryption, o HPKE, pueden utilizar junto con una derivación de claves y un algoritmo de cifrado simétrico como AES-GCM. ML-DSA ofrece un modelo más cercano a Ed25519 y ECDSA, ya que genera un par de claves, firma los datos y verifica la firma.
¿Por qué es importante esta noticia?
La transición al cifrado resistente a la computación cuántica no se realiza mediante un único cambio, sino que requiere actualizar los protocolos, las bibliotecas, los servicios y los entornos de implementación. Cloudflare afirma que proporcionar primitives nativas dentro de Web Crypto reduce la necesidad de incluir una implementación criptográfica propia con cada biblioteca y ofrece a los desarrolladores un punto práctico para probar integraciones como la firma de JWT mediante ML-DSA o el uso de ML-KEM dentro de HPKE, algo relacionado con protocolos como OHTTP.
En la práctica, este cambio no convierte automáticamente las aplicaciones de Workers en aplicaciones resistentes a la computación cuántica ni ofrece una ruta completa de actualización para ningún protocolo. Solo proporciona los componentes básicos, mientras que los desarrolladores de bibliotecas deben elegir el protocolo, los conjuntos de cifrado y los mecanismos de compatibilidad adecuados.
Limitaciones y próximos pasos
Workers implementa estas funciones en la capa Web Crypto dentro del entorno workerd, basado en V8, y utiliza primitives de BoringSSL. La incorporación incluyó pruebas de Web Platform Tests, pruebas específicas para la etiqueta de compatibilidad y nuevas definiciones de TypeScript.
La fase actual no incluyó otros algoritmos contemplados en la propuesta moderna de Web Crypto, como SHA-3, cSHAKE, TurboSHAKE y ChaCha20-Poly1305, y HPKE tampoco pasó a formar parte de la propia interfaz de Workers. Cloudflare señala que las claves y firmas de ML-DSA son mucho más grandes que sus equivalentes en RSA o Ed25519; por ello, reducir el coste de incluir la implementación y mejorar el rendimiento no elimina el impacto del aumento del tamaño de las claves, las firmas y los textos cifrados en la red o el almacenamiento.
La cuestión de convertir la compatibilidad en el modo predeterminado sigue abierta hasta que el borrador se estabilice y se obtengan comentarios de los desarrolladores de bibliotecas. Por tanto, la incorporación debe considerarse una herramienta para experimentar y validar la integración, no una señal de que todas las aplicaciones estén listas para realizar una transición inmediata.