jasmin and wasi?

[spitters]

Jasmin is a high level assembly which compiles to both x86 and ARM.
It is popular among cryptographic engineers. It would be interesting to make jasmin available to wasm too.
Would WASI be the right vehicle to do that?

[jedisct1]

Jasmin is a fantastic project, and it could emit WebAssembly byte code, but:

• byte code cannot be directly used by applications. It would probably need to fully support building WebAssembly modules as well as the component model, which represents a ton of work, not to mention maintenance afterwards.
• WebAssembly support for SIMD is fairly limited.
• WebAssembly doesn't make any guarantees regarding constant time code. Runtimes can do whatever they want. This also makes verification complicated and certification impossible.

Jasmin can absolutely be useful to build optimized native implementations that WebAssembly modules can call via hostcalls (WebAssembly's version of system calls). Not so much to generate WebAssembly code.

I would personally rather see seamless Jasmin integration in other compilers, such as the ability to generate assembly code via Jasmin at compile time in Zig.

[spitters]

Yes, I was wondering about using jasmin for native implementations.
Jasmin implementations are fast. Has anyone looked at how they compare to the native implementations currently supported by WASI?

Regarding constant time, I'm sure you're aware of https://github.com/PLSysSec/ct-wasm

[jedisct1]

WASI-crypto implementations currently use BoringSSL and OpenSSL under the hood.

So, having Jasmin-produced code merged there would help a ton of existing applications, including WASI.

ct-wasm is a proposal. It's not implemented in any runtime nor supported by any language.

Specialized instruction sets such as AESNI also don't exist. Neither do basic things such as ADCX/ADOX. So, performance is never going to be as good as native implementations anyway.

[spitters]

Thanks!
I guess the usual trade-offs apply for OpenSSL vs rusTLS.
The former may be slightly faster, whereas the latter is memory safe.

BoringSSL already uses high assurance cryptography via fiat-cryptography

[jedisct1]

Yep, fiat-crypto is now used everywhere in the Zig and Go standard libraries for field arithmetic, and BoringSSL is using it for 25519 and non-optimized p256. This is a big step towards high assurance cryptography.

Using Jasmin would logically be the next step to further improve performance while retaining high-assurance, and I'm really looking forward to it.

RusTLS is actually using BoringSSL for all cryptographic operations. So improvements to BoringSSL will benefit to it as well.