#428 added decoupled crypt backends.
I'm trying to implement a WebCrypto backend but I've hit a wall: CryptoProvider is synchronous.
The WebCrypto API (SubtleCrypto.sign(), .verify(), .importKey()), however, is entirely Promise-based. On wasm32, there is no way to block on a Promise. This makes it impossible to implement CryptoProvider using WebCrypto.
The rust_crypto backend does compile to wasm32 and works, but it means bundling a full Rust crypto implementation into the WASM binary instead of using the browser's native
(and hardware-accelerated) crypto.
Proposal
Add an async counterpart to CryptoProvider so that WebCrypto (and other async crypto backends like cloud KMS) can be used.
The RustCrypto ecosystem already provides async-signature with an AsyncSigner trait that mirrors signature::Signer but with async fn
Alternatives considered
- Use rust_crypto on wasm32: Works today, but bundles ~100KB+ of Rust crypto into the WASM binary instead of using the browser's built-in crypto.
- Async wrappers outside the crate: Provide standalone encode/decode functions that bypass CryptoProvider entirely. Works but duplicates logic and doesn't benefit from the abstraction.
#428 added decoupled crypt backends.
I'm trying to implement a WebCrypto backend but I've hit a wall:
CryptoProvideris synchronous.The WebCrypto API (SubtleCrypto.sign(), .verify(), .importKey()), however, is entirely Promise-based. On wasm32, there is no way to block on a Promise. This makes it impossible to implement CryptoProvider using WebCrypto.
The rust_crypto backend does compile to wasm32 and works, but it means bundling a full Rust crypto implementation into the WASM binary instead of using the browser's native
(and hardware-accelerated) crypto.
Proposal
Add an async counterpart to CryptoProvider so that WebCrypto (and other async crypto backends like cloud KMS) can be used.
The RustCrypto ecosystem already provides async-signature with an AsyncSigner trait that mirrors signature::Signer but with async fn
Alternatives considered