Remove Boring SSL

[rjzak]

Remove Boring SSL, only used in implementations/hostcalls/rust/src/signatures/rsa.rs.

Motivation:

• We want to support wasi-crypto in Enarx, but our Wasm component is compiled as x86_64-unknown-linux-musl, which conflicts with Boring since it's in C++.

In-Progress:

• rjzak/wasi-crypto using RustCrypto/RSA.

CC: @jedisct1

[jedisct1]

That would be a dealbreaker for us.

Ignoring security concerns, the pure Rust RSA implementation is very slow. Way too slow for our requirements, and it doesn't even justify using hostcalls vs compiling to WebAssembly.

The RSA crate was originally used in that code, and got eventually replaced with BoringSSL for that reason.

Is C++ incompatible with static builds? That looks like a toolchain issue, a configuration issue, or something to fix in the boring crate rather than a permanent obstacle.

[rjzak]

Could we have a compromise where a feature flag could select RustCrypto over Boring? I'll take a closer look at Boring to see about the compilation issue. But Boring + Rust + musl results in trying to use musl-g++ (not resolved with sudo ln -s /bin/g++ /bin/musl-g++), and the compiler not finding several standard header files.

CC: @npmccallum

[jedisct1]

The boring crate seems to always try to compile to the host architecture (compiling with cargo-zigbuild build --host=x86_64-unknown-linux-musl still makes it try to compile for ARM on my M1 Mac). But fixing this would make a lot of people happy :)

[rjzak]

Out of curiosity, what would you say was the performance boost by switching to boring?

[tarcieri]

I’m curious to know as well. We should open a tracking issue on the rsa crate about the performance difference

[jedisct1]

Benchmark of JWT verification/signature:

(C@E module is pure WebAssembly)

[npmccallum]

@jedisct1 Did you build rsa in release mode with all the optimizations on?

[jedisct1]

Of course, yes.

[jedisct1]

boring already has some support for cross-compilation, as it can cross-compile for Android and iOS (see get_boringssl_cmake_config in the build.rs file).

[npmccallum]

@jedisct1 boring is a non-starter for Enarx given our hardware environment. Can we have both implementations behind a feature flag?

[PiotrSikora]

FYI, there is also bssl-sys crate (still under development?) by BoringSSL team. Perhaps that could work?

[npmccallum]

@PiotrSikora We will not use boring.

[PiotrSikora]

@npmccallum the original comment complains about C++ (which last time I checked, was optional in BoringSSL, and perhaps it being required is an issue with boring crate). I didn't use bssl-sys, but it looks like it's using bindgen, so it should be pure C. Is your issue with using BoringSSL in general or with the C++ bits?

[jedisct1]

It shouldn't be too hard to support both. So, yes, it looks like a good path forward.

[npmccallum]

@PiotrSikora We have historically tried boring, openssl, and mbed. Trying to use them in our context causes a lot of problems (not just C/C++). We gave up after months of pain and now use RustCrypto for everything.