A Cloudflare adicionou ao ambiente Cloudflare Workers suporte opcional aos algoritmos de criptografia resistentes à computação quântica ML-KEM e ML-DSA na interface Web Crypto. A mudança permite que os desenvolvedores testem alternativas modernas para troca de chaves e assinaturas digitais usando interfaces nativas no ambiente de execução, em vez de incluir implementações separadas em JavaScript ou WebAssembly.
O suporte está atualmente disponível por meio da flag de compatibilidade webcrypto_modern_algorithms, porque a interface dos algoritmos modernos ainda se baseia em um rascunho sujeito a alterações. A primeira versão oferece suporte a ML-KEM-768 para encapsulamento de chaves e ML-DSA-44 para assinaturas, além de também disponibilizar ML-KEM-1024, ML-DSA-65 e ML-DSA-87. Já o ML-KEM-512 não é compatível porque a versão do BoringSSL usada no Workers não o disponibiliza.
O que a nova interface oferece?
A adição inclui as operações encapsulateBits(), decapsulateBits(), encapsulateKey() e decapsulateKey(), além de getPublicKey(), SubtleCrypto.supports() e da importação e exportação de chaves JWK para esses algoritmos. A interface de verificação de suporte permite que as bibliotecas evitem presumir a disponibilidade dos algoritmos em todos os ambientes JavaScript, especialmente ao executar código por meio de Workers, Node.js, Deno e navegadores.
O ML-KEM não implementa sozinho a criptografia completa; ele produz material de chave compartilhada que protocolos como o Hybrid Public Key Encryption, ou HPKE, podem utilizar com derivação de chaves e um algoritmo de criptografia simétrica, como o AES-GCM. Já o ML-DSA oferece um modelo mais próximo do Ed25519 e do ECDSA, pois gera um par de chaves, assina dados e verifica a assinatura.
Por que esta notícia é importante?
A transição para a criptografia resistente à computação quântica não ocorre por meio de uma única substituição, mas exige a atualização de protocolos, bibliotecas, serviços e ambientes de implantação. A Cloudflare afirma que disponibilizar primitives nativas dentro do Web Crypto reduz a necessidade de distribuir uma implementação criptográfica própria com cada biblioteca e oferece aos desenvolvedores um ponto prático para testar integrações como a assinatura de JWT usando ML-DSA ou o uso de ML-KEM dentro do HPKE, algo relacionado a protocolos como o OHTTP.
Na prática, essa mudança não transforma automaticamente os aplicativos Workers em aplicativos resistentes à computação quântica, nem oferece um caminho completo de atualização para qualquer protocolo. Ela fornece apenas os blocos básicos, enquanto cabe aos desenvolvedores das bibliotecas escolher o protocolo, os conjuntos de cifras e os mecanismos de compatibilidade adequados.
Limitações e próximos passos
O Workers implementa essas funções na camada Web Crypto dentro do ambiente workerd, construído sobre o V8, com base em primitives do BoringSSL. A adição incluiu testes do Web Platform Tests, testes específicos para a flag de compatibilidade e novas definições de TypeScript.
A etapa atual não incluiu outros algoritmos presentes na proposta moderna do Web Crypto, como SHA-3, cSHAKE, TurboSHAKE e ChaCha20-Poly1305, e o HPKE também não passou a fazer parte da própria interface do Workers. A Cloudflare ressalta que as chaves e assinaturas ML-DSA são muito maiores do que suas equivalentes em RSA ou Ed25519; portanto, reduzir o custo de incluir a implementação e melhorar o desempenho não elimina o impacto do aumento dos tamanhos das chaves, assinaturas e textos cifrados na rede ou no armazenamento.
A questão de transformar o suporte em padrão continua em aberto até que o rascunho se estabilize e sejam obtidos comentários dos desenvolvedores de bibliotecas. Por isso, a adição deve ser tratada como um meio de experimentação e validação da integração, e não como um sinal de que todos os aplicativos estão prontos para uma transição imediata.