Ralph (Oct 18 2024 at 14:59): Ralph (Oct 18 2024 at 14:59):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.
Ralph (Oct 18 2024 at 15:00):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?
Lann Martin (Oct 18 2024 at 16:58):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.
Ralph (Oct 18 2024 at 16:59):yup, totes get it. The question would definitely be how are we thinking about the future of this area...
Ralph (Oct 18 2024 at 17:00):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.
Chris Fallin (Oct 18 2024 at 17:00):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
Chris Fallin (Oct 18 2024 at 17:00):(but then I'm a VM isolation + verification person, not a crypto person, so the opposite bias might lead to the opposite answer!)
Ralph (Oct 18 2024 at 17:01):absolutely understand
Lann Martin (Oct 18 2024 at 17:06):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.
Ralph (Oct 18 2024 at 17:07):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.
Pat Hickey (Oct 18 2024 at 17:10):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
Pat Hickey (Oct 18 2024 at 17:11):that takes care of the preapproved implementation for a lot of contexts (web, node.js)
Lann Martin (Oct 18 2024 at 17:15):(or will, once JSPI lands :smile:)
Pat Hickey (Oct 18 2024 at 17:18):real soon now
bjorn3 (Oct 18 2024 at 18:32):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.
bjorn3 (Oct 18 2024 at 18:39):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/
Lann Martin (Oct 18 2024 at 19:25):Yeah I would maybe frame it as making the interface "webcrypto-compatible", e.g. perhaps use resources for secret keys
bjorn3 (Oct 18 2024 at 20:03):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?
Lann Martin (Oct 18 2024 at 20:09):Enum variants are encoded as ints by the ABI
Lann Martin (Oct 18 2024 at 20:10):but iirc the component type binary uses the labels, so it really depends what you mean by ABI
Lann Martin (Oct 18 2024 at 20:12):i.e. I would still expect it to break linking of existing components
Dave Bakker (badeend) (Oct 19 2024 at 07:22):Or mark them as @deprecated
Pat Hickey (Oct 19 2024 at 15:29):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.
Pat Hickey (Oct 19 2024 at 15:35):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.
Pat Hickey (Oct 19 2024 at 15:37):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: Nov 22 2024 at 16:03 UTC