hey everyone, internally we have "approval boards" for things like crypto libraries, and someone wants to use wasm components (yay!) and the "approval board" asked about the crypto libs with the intention of asking to approve them.
now we're way early for that, but exactly how do we see this kind of lib appearing? Do we see a standalone lib for that, or implementations to provide their own by bringing in standard C/Rust impls to the component?
I'm not sure that there is one blanket answer to this one. For some cryptographic operations a board might not approve any wasm guest implementation today because wasm doesn't have constant-time operations.
yup, totes get it. The question would definitely be how are we thinking about the future of this area...
I think @Dave Bakker (badeend) did some great work with wasi:tls, and I'm wondering about a more general approach to that kind of thing.
It's worth noting as well that there are some interesting isolation/sandboxing vs. crypto-properties tradeoffs here. Historically in wasmtime, wasi-crypto has had a ... checkered ... history because of memory-safety issues. Personally I'd love to see something like Alex and Jamey's work on 128-bit arithmetic performance, plus any thinking needed around constant-time ops, to allow for performant+compliant impls on the guest side
(but then I'm a VM isolation + verification person, not a crypto person, so the opposite bias might lead to the opposite answer!)
absolutely understand
In the near term a wasi:tls-like approach would be to pick a type of cryptographic operation like "symmetric block encryption", define a generic interface for that operation, then use some existing (preapproved, even) implementation(s) on the host. Depending on what level of abstraction these things get evaluated at you might not even need separate approval for wasm.
I wouldn't actually get those peepz on wasm per se, but on a block of something, as you suggest.... that's a good path.
i think a really great starting point is to render the webcrypto api in wit https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API
that takes care of the preapproved implementation for a lot of contexts (web, node.js)
(or will, once JSPI lands :smile:)
real soon now
Web crypto has various algorithms that absolutely should have huge warnings to never ever use them unless you need to interact with an existing system that uses them. For example encryption without authentication. Also for whatever reason the AES-GCM interface allows passing an arbitrary nonce rather than generating an appropriate one automatically. Nonce reuse trivially breaks AES-GCM. For asymetric encryption it only supports RSA-OAEP rather than something like HPKE. The latter also uses elliptic curves rather than RSA. And for encryption, signing, key derivation and key wrapping they are mixing symmetric and asymetric algorithms in a single api despite their widely different semantics.
Please let a proper cryptographer review whatever api you come up with to make it misuse resistant rather than blindly adopting a W3C standard: https://blog.cryptographyengineering.com/2012/12/28/the-anatomy-of-bad-idea/
Yeah I would maybe frame it as making the interface "webcrypto-compatible", e.g. perhaps use resources for secret keys
If you rename an enum variant in wit (eg digest.sha1 to digest.broken-sha1) while keeping it in the same index within the enum is that an abi break or just an api break?
Enum variants are encoded as ints by the ABI
but iirc the component type binary uses the labels, so it really depends what you mean by ABI
i.e. I would still expect it to break linking of existing components
Or mark them as @deprecated
Yeah we have the advantage of hindsight here, the web can’t ever unship something but we can mark things as deprecated. If it’s totally buggy and no reasonable application could possibly use something we could choose to never expose it at all, but that’s a high bar.
What I’m more worried about is making wasi crypto the venue for old grudges to get resolved and to try to invent a new way to expose crypto that definitely won’t repeat any of the mistakes all those other ones made.
I’d like to be less ambitious about being perfect, or even at improving the status quo, and just ship. There’s been a glaring need from many different users and platforms to provide crypto primitives and keep secrets opaque behind a resource for many years now.
Last updated: Dec 23 2024 at 12:05 UTC