bupstash

bupstash copied to clipboard

I had a look at the code to see how libsodium was used. What's your take on dropping libsodium in favor of a pure Rust implementation like https://github.com/typed-io/cryptoxide/? I don't know about the maturity of this particular implementation, I just picked one that seemed to have support for curve 25519 chacha 20 poly 1305 as an example.

The reason I'm asking is because it would simplify the build process, especially cross compilation for things like musl ARM. I eventually want to use this on a Synology device. If you're not interested in dropping libsodium, would it be OK to do so behind a without-libsodium feature flag? Of course a fewer usages of unsafe is nice too, but that's not my main concern.

Sure, I mainly was interested in performance, which is something we can measure. There is actually a hidden cli command specifically for benchmarking this stuff from stdin where you can just pipe in data.

One reason we use lz4 instead of zstd is it had a pure rust option too.

Just for fun, I had a look into it. Here are some notes and observations.

The crate libsodium-sys-0.2.7 is pretty much a drop-in replacement for the generated bindings. While it still uses the libsodium from the system, it removes the need for bupstash to provide its own bindings. It does not help with reducing the use of unsafe Rust.

It looks like the cryptoxide-0.4.2 crate does not provide the crypto box API from libsodium. The crate crypto_box-0.8.1 does not expose the equivalent of crypto_box_curve25519xchacha20poly1305_beforenm, whose result is used to compute a BoxKey. The ChaChaBox::new function appears to do the same thing, but it forgets the key so it is not possible to call blake3::keyed_hash. The crypto_box crate comes from the RustCrypto project and it uses other crates from that project, whereas cryptoxide is monolithic fork of RustCrypto that has no external dependency. Apparently, some parts of RustCrypto (including crypto_box) have been subject to a security audit. Not sure what is the status of cryptoxide with respect to that.

Currently, libsodium is also used for base64 encoding, but I guess the base64 crate would do just as well.

Thanks for investigating - The main reason we have our own libsodium-sys type bindings was so I could avoid the build time dependency on bindgen - there might be an option to avoid this now though so it could be worth looking at it again.