Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Use case] crypto #1526

Open
ppenzin opened this issue Aug 14, 2024 · 4 comments
Open

[Use case] crypto #1526

ppenzin opened this issue Aug 14, 2024 · 4 comments

Comments

@ppenzin
Copy link

ppenzin commented Aug 14, 2024

Summarizing some disjoint threads. #1522 which is going to phase 1 listed implementing crypto and other large-number mathematical primitives as a leading motivation. We have had two suggestions along these lines in the past: #1433 (AES-NI) and #1388 (CLMUL). Since then @danleh has noticed references to encryption routines in one popular messaging app. A significant reason why the crypto wasn't moving forward is that there are Web APIs for encryption, as well as we encryption in the browser itself. I wonder if we need to revisit that and also include other adjacent use cases, such as pseudorandom numbers, hashes, large ints, etc.

@ppenzin
Copy link
Author

ppenzin commented Aug 14, 2024

/CC @jameysharp

@kripken
Copy link
Member

kripken commented Aug 14, 2024

there are Web APIs for encryption

Off the Web, there is wasi-crypto (seems to be at phase 1).

@jameysharp
Copy link

It's worth bearing in mind that the cryptographic applications of arbitrary-precision arithmetic, as we're discussing in #1522, are entirely unrelated to AES. You need big integers to implement certain public-key cryptography algorithms like RSA, not for symmetric-key cryptography like AES or for hashes like SHA-2.

So #1433, for example, is a good idea that is complementary to #1522, not a viable alternative to it. Lumping all of these together under the use case of "cryptography" misses some important distinctions between them.

It's also important to remember that the Web Crypto and wasi-crypto APIs do not and cannot address all cryptography use cases. The field is constantly evolving, standardization and implementation necessarily lag behind, and both APIs have carved out a widely-used but narrowly-defined scope of the kinds of algorithms they'll support.

For example, as best I can tell, neither API supports the primitives required for generating RSA Blind Signatures, as used in specifications like Privacy Pass. It's not clear to me that they can or should fit the necessary functionality into their existing APIs, either. That was my original motivation for looking into this, personally.

So I fully support this proposal to investigate more ways that WebAssembly can directly support the kinds of computation that cryptographers are using in research and new standards. I expect we'll find there are a variety of useful directions to explore in addition to #1522, such as constant-time extensions as in #1299.

@ppenzin
Copy link
Author

ppenzin commented Aug 15, 2024

@jameysharp my intention with this was orthogonal to #1522, but rather seeing if we are missing out on some important use cases in the broader problem space. Maybe 'crypto' catchall is somewhat misguided, as there are very different things involved, though I do want to highlight that these are the problems we were considering outside of the scope. The idea is to hopefully narrow things down to a few directions (#1299 is interesting in that regard, because it explores hardening the spec as opposed to adding support for hardware acceleration).

@ricochet has shared a couple of videos at the meeting, I've found a reference to OpenSSL in Wasm + Kubernetes: Beyond Containers, though it seems to imply that in the browser OpenSSL is using WebAPIs. I am not entirely sure, haven't located the implementation they were using. There is wasm-openssl which seems to be a native wasm build, judging from the configure line. Tagging @cryptable, who owns that repo.

If there is enough interest we should consider exploring more support, at least moving #1433 into a proposal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants