Ralph (Aug 14 2024 at 13:04): Ralph (Aug 14 2024 at 13:04):Anyone have a good sense of where wasi-crypto is as a proposal? I see it, but somehow it doesn't seem like the final version that people are looking for. What do people think? tag: @Pavel Šavara
Pavel Šavara (Aug 14 2024 at 13:08):I'm no crypto expert, but yesterday we discusses with @Joel Dice that we will need to build TLS for many networking protocols on top of wasi-socket. For example database connections.
Pavel Šavara (Aug 14 2024 at 13:08):The scope of algos supported by dotnet could be understood from
https://learn.microsoft.com/en-us/dotnet/standard/security/cross-platform-cryptography
Pavel Šavara (Aug 14 2024 at 13:10):Our lesson from dotnet on browser: Browsers only have async APIs in SubtleCrypto. C# crypto APIs are synchronous. There is no way how we can use browser APIs in single threaded dotnet. (sync over async wrapper is impossible without threads/blocking. Possibly JSPI could help us to overcome that when it's supported widely) .
Ralph (Aug 14 2024 at 13:10):There's a lot of code out there to do this, but we'd need to understand how wasi:crypto should be shaped first and secondarily how wamr/wasmtime might implement it above and beyond what they have now.
Dave Bakker (badeend) (Aug 14 2024 at 13:44):@Pavel Šavara For the database connections use-case, is dotnet intending to create their own TLS stack? And therefore need access to the raw, low level crypto primitives?
Or do you want a TLS transform interface, which can be as simple as:
wrap-tls: func(input: input-stream, output: output-stream, server-name: string) -> tuple<input-stream, output-stream>
Or something in between?
Joel Dice (Aug 14 2024 at 14:10):@Alex Crichton and I spent some time brainstorming ways to support TLS for various guest languages (JS and .NET in particular, since they're priorities for us right now) last week. The conclusion we came to (and which I shared with @Pavel Šavara yesterday) is that the most practical way forward is to add a wasi:sockets/tls interface per the issue Dave linked to above (see also this presentation).
Specifically, we'd like to create a draft of that interface by selecting a representative sample of database client libraries which use System.Net.Security.SSLStream in the .NET ecosystem and NodeJS's tls module in the JS ecosystem, constructing a minimal implementation that makes those libraries work. I.e. we'd port just enough of .NET's SSLStream etc. and Node's tls to a draft of wasi:sockets/tls, starting with nothing and adding features to that draft as needed, until the libraries work.
Per the above discussion, an alternative would be to come at the problem from the other direction: start with (an updated version of) wasi:crypto and build (or port) a TLS library to use it, with the high level code living in the guest and deferring to wasi:crypto for the primitives. I'm personally reluctant to go that route since it would seem to require both more expertise and effort, although I certainly wouldn't complain if someone else wanted to tackle it. I do agree that updating wasi:crypto would be valuable, but I'm not convinced it's the most expedient route to supporting libraries that just need TLS.
Pavel Šavara (Aug 14 2024 at 14:13):Short answer, I don't know because crypto is new area for me.
I think we want low level symetric/asymetrics and hashing algos as for sure, because we expose APIs for those.
I know we have SslStream API. I don't know the implementation details.
I think that we dynamically link openSSL on Linux but I don't know if we use TLS from there for HTTPS or we build our own.
I know we have implementation of HTTP2 in MsQuic (which is native lib), but again I don't know the details yet.
For sure we consume available (certified) crypto API differently on different OS. See the link above.
Possibly the TLS stream you linked could be be a stop-gap solution.
I don't know if that would be enough for MSFT certified solution. (that would be for our crypto experts to judge)
Dave Bakker (badeend) (Aug 18 2024 at 21:11):@Joel Dice I have created a draft interface in the issue above (https://github.com/WebAssembly/wasi-sockets/issues/100).
Dave Bakker (badeend) (Aug 18 2024 at 21:18):The APIs in that draft are not based on any particular use-case, but rather gut feeling. Nonetheless, I think it is a reasonable foundation to start adding/removing properties based on real-world usage.
Last updated: Nov 26 2024 at 00:12 UTC