A major motivation for the wasi-crypto submodule is the ability for a host to act as a HSM.
It makes sense to not restrict the API to that, and provide a set of commonly required cryptographic functions, that all languages targeting WebAssembly can immediately benefit from.
However, what about e.g. finite field arithmetic? On one hand, operations described in #18 are absolutely required to implement some protocols. Their absence is a reason why people have to use potentially unsafe alternatives to WebCrypto at the moment. On the other hand, these are not required from a HSM and could totally be implemented in a guest module. We could even provide reference code for such a module, designed to work in tandem with the wasi-crypto API.
Why is it unsafe to do so that the moment?
WebAssembly doesn't provide any guarantees against resistance to side-channel attacks. The diversity of runtimes makes it impossible to verify that code originally written to be constant-time will actually be constant-time.
There isn't any ways to ensure that secrets are cleared from memory either.
The CT-Wasm (1) (2) (3) proposal addresses all these concerns, but isn't part of the WebAssembly specification yet.
Beyond CT-Wasm, implementers may have expectations, such as the fact that conditional moves, for which WebAssembly has an opcode for, is free of side channels. But this isn't mandated by the specification yet.
Performance concerns
WebAssembly doesn't currently support hardware crypto acceleration.
AES-NI, in particular, would be a really useful addition. Software implementations either have side channels, or are way slower than their hardware counterpart.
For big number arithmetic, add with carry and sub with borrow would be extremely useful opcodes to have.
What can we do?
It may be out of the scope of wasi-crypto. However, anything that could safely be done in a guest module doesn't have to be part of wasi-crypto. Or, from a different perspective, everything that cannot safely be implemented in a guest module must be part of wasi-crypto.
Maybe we can help. Starting with discussing how WebAssembly itself could be improved to make it a trusted target for implementing cryptography, not ignoring existing efforts such as ct-wasm.
A major motivation for the
wasi-crypto
submodule is the ability for a host to act as a HSM.It makes sense to not restrict the API to that, and provide a set of commonly required cryptographic functions, that all languages targeting WebAssembly can immediately benefit from.
However, what about e.g. finite field arithmetic? On one hand, operations described in #18 are absolutely required to implement some protocols. Their absence is a reason why people have to use potentially unsafe alternatives to WebCrypto at the moment. On the other hand, these are not required from a HSM and could totally be implemented in a guest module. We could even provide reference code for such a module, designed to work in tandem with the
wasi-crypto
API.Why is it unsafe to do so that the moment?
WebAssembly doesn't provide any guarantees against resistance to side-channel attacks. The diversity of runtimes makes it impossible to verify that code originally written to be constant-time will actually be constant-time.
There isn't any ways to ensure that secrets are cleared from memory either.
The CT-Wasm (1) (2) (3) proposal addresses all these concerns, but isn't part of the WebAssembly specification yet.
Beyond CT-Wasm, implementers may have expectations, such as the fact that conditional moves, for which WebAssembly has an opcode for, is free of side channels. But this isn't mandated by the specification yet.
Performance concerns
WebAssembly doesn't currently support hardware crypto acceleration.
AES-NI, in particular, would be a really useful addition. Software implementations either have side channels, or are way slower than their hardware counterpart.
For big number arithmetic, add with carry and sub with borrow would be extremely useful opcodes to have.
What can we do?
It may be out of the scope of
wasi-crypto
. However, anything that could safely be done in a guest module doesn't have to be part ofwasi-crypto
. Or, from a different perspective, everything that cannot safely be implemented in a guest module must be part ofwasi-crypto
.Maybe we can help. Starting with discussing how WebAssembly itself could be improved to make it a trusted target for implementing cryptography, not ignoring existing efforts such as
ct-wasm
.Thoughts?