Cryptography Module

[beriberikix]

I was curious if there has been any thought about a Cryptography module, or if this is a good place to start a conversation. As JF Bastien points out, one shouldn't implement crypto for Wasm targeting the browser due to security concerns, especially since the browser provides highly-optimized and more secure Web Crypto APIs that run outside the JS context. So with WASI and the lack of the browser, where should crypto live?

Coming from an Embedded electronics/IoT background, it's pretty common for an application to include a library like mbed TLS. It is optimized for the hardware architecture of the host, to be as resource-efficient as possible and leverage hardware-acceleration whenever possible (this is usually handled by build-time configuration.) I'm not familiar with the details of OpenSSL but I believe it is similar.

To that end, what would a Cryptographic module look like, and what concerns would need to be considered? Could it be based on something like mbed TLS?

Love to hear y'alls thoughts!

[jedisct1]

A couple things here.

Why is it a bad idea to have implementations of cryptographic primitives written in Javascript or WebAssembly? (which, by the way, extends beyond web browsers).

Because it is difficult to predict how the code will be compiled. JITs can apply unwanted optimizations that will turn code supposed to be constant-time into variable-time, creating side channels.

With the deluge of recent architectural side channels, modern browsers have mitigations making side channel exploitation generally more difficult. But still, side channels should be avoided in the first place.

Now, here is why being able to implement cryptography in Javascript or WebAssembly is not only a good thing, but also mandatory: quite often, the only alternative would be no cryptography. Possible side channels are better than no security at all.

The WebCrypto API is too limited to implement many protocols. Which is why so many applications have to use libraries such as libsodium.js or sjcl. Another justification, at least for libsodium.js, is interoperability: the same library, with the exact same primitives and APIs, can be used server-side in other languages.

Unwanted optimizations is something that can be solved by WebAssembly, by introducing a way to taint a value as holding sensitive data. In addition to avoiding generating non-CT code when manipulating these values, compilers could automatically zero them when they are not used any more.

CT-Wasm is also an excellent proposal to address this.

Instead of "do not use WebAssembly to write crypto", I'd rather see WebAssembly support this.

That being said, having a WASI cryptographic module would be an excellent thing as well. Since it will need to run in a browser context, it seems natural to leverage the existing WebCrypto API.

The WebCrypto API has been, and keeps being heavily criticized. It was a huge disappointment to see it being designed like legacy crypto libraries. It only provides a set of low-level primitives, with many parameters to choose from, delegating the responsibility of using them correctly to the user. Since this kind of API has proven to be the root cause of most crypto disasters, the current trend, that already started when WebCrypto was designed, is rather to provide high-level APIs that are easy to use and hard to misuse. These APIs provide operations, not primitives, enforcing safe constructions and parameters. Even Apple recently revamped their crypto APIs to fit this pattern.

If a WASI crypto module is being designed, it should hopefully not repeat the WebCrypto mistake, but offer a modern API instead. Which doesn't prevent it from, under the hood, using WebCrypto primitives.

That being said, the first point (making WebAssembly a trusted platform for running cryptographic implementations) should probably be addressed first.

[sunfishcode]

As a practical matter, CT-Wasm or other possible CT extensions to wasm are topics that should be discussed at the CG level, rather than in the WASI subgroup, as they would require significant language-level changes.

I don't think we need to address CT features first through. Higher-level crypto APIs aren't alternatives to having CT features into the platform, as they address sufficiently different needs. Among other things, these crypto APIs can make use of cryptographic accelerators in hardware. As such, we can begin designing crypto APIs when we're ready, and treat CT features as an independent concern.

[sunfishcode]

As an update here, constant-time extensions to wasm were presented at the last in-person CG meeting, and one outcome of this is that there is now a proposal repo for further developing the proposal. I encourage folks interested in CT-WASW to follow up there!

With that, a WASI cryptography module is still something which makes sense to discuss, because it could utilize native accelerated implementations, including hardware accelerators, and integrate with host key management mechanisms.

[linclark]

This one is now being actively addressed in other repos, so I'm going to go ahead and close this one out.

A high-level API is being developed in wasi-crypto, and CT-Wasm provides lower level building blocks for developers who want to do something different.