[Feature] Use Libsodium instead of Bouncy Castle

[Jack-Edwards]

As I began working on other features in the v1.8 milestone, I made the decision to switch from the Bouncy Castle portable class library to Libsodium through libsodium-core. I believe switching to Libsodium will drastically improve cryptographic performance in the browser. For instance, xchacha20poly1305 and XSalsa20 are used instead of AES. AES is so widely used and performant because it is hardware-accelerated. There's no such hardware-acceleration for AES when using the Bouncy Castle PCL.

One caveat to switching to Libsodium is that it contains a different set of interfaces. Using the lib-sodiumcore Nuget package, public/private keys are nothing more than byte[]. nsec is another popular C# language binding for Libsodium which imports and exports key "blobs". Maybe this is better, and maybe I'll try switching to nsec instead, but the point is both libraries have their own interfaces which differ from Bouncy Castle.

Either way, the cryptography library being used needs to be decided on and implemented prior to providing users with account recovery keys. Recovery keys issued during the Bouncy Castle phase of Crypter will not be compatible with the Libsodium phase. I'm not going to mislead users by giving them recovery which won't work later on after the switch is made. And unfortunately, I can't proceed with my idea of "persistent file storage" either for the same reason.

Libsodium is fully integrated into Crypter and every project in the solution builds without errors. Unit tests are passing as well.

However, getting Libsodium to work as a NativeFileReference has been a challenge. Steps thus far:

• Run this wasm32-wasi.sh script from the Libsodium stable branch to produce a libsodium.a file. I ran this on a Linux VM. The script requires a WASI runtime available, which was just simpler to get working on a Linux VM than on my Windows PC.
• Add <NativeFileReference Include="Native\libsodium-wasm32-wasi\lib\libsodium.a" /> to Crypter.Web.csproj.
• Copy the libsodium.a file to the path specified above.
• If using libsodium-core, then you need to modify the source with the changes from this Pull Request Get interop working with Mono AOT. Use this modified version of the library instead.

Crypter.Web will build and can run in the browser, but the cryptographic functions will not work. That's been a whole conversation on this issue and others.

I believe the next step is to get a WASI implementation bundled into the web application or linked during build. Frank Denis suggested trying to use wasmer-js, but there is an open issue on how to even get the library working in the browser, as there are no instructions on how to satisfy the Buffer global dependency. How to use in browsers?.

There is also this open issue which indicates the runtime team is working on support for WASI-enabled builds. Will wait and see.