Another encrypted volume implementation

[Mivik]

Some days ago I was seeking for a cross-platform way to store data securely. At that time, I couldn't find such a project and assumed there was no proper way to accomplish this, eventually leading me to develop my own solution. So I made Bijou, a cross-platform and flexible encrypted file system. The library currently has a FUSE interface.

I discovered this project while making a Android app for Bijou. This project is great! So rather than starting from scratch, I convinced myself to extend this existing project.

Some advantages over existing implementations that I could think of include:

1. Less work is needed to integrate since Bijou provides documented API interface
2. Better performance
3. Bijou supports (hard of soft)links, xattrs, etc., regardless of the underlying file system

Drawbacks exist as well. For instance, Bijou is not as thoroughly tested as other implementations and should be considered experimental.

I look forward to hearing your opinions on this. Feel free to ask me details regarding Bijou, and it's totally okay if you suggest some features / tweaks for BIjou. It's still in the early development stage anyway.

[hardcore-sushi]

Wow, it seems like a very cool project. However, I don’t understand what exactly is stored in RocksDB, and why did you need to patch it?

What is the advantage over CryFS (except performance)?

[Mivik]

Files are identified by unique IDs, and the underlying storage is only responsible for storing the content of that file by ID. The actual metadata of the files (filenames, directory hierarchy, permissions, etc.) is stored in RocksDB. Since RocksDB does not support encryption (actually they have one implementation, but is rather limited and only capable of really basic encryption), I patched it to support custom encryption.

Advantages over CryFS, if leave aside performance (which is really significant according to a comparison), are, to be honest, scarce and trivial:

1. Filesystem features; hardlinks, xattrs
2. Easier and neater integration
3. Customizable storage backend (maybe even Android DocumentsProvider?)

As a side note, Bijou supports file size obfuscation (which is one of the main features of CryFS) as an optional functionality. However, the implementation in Bijou is less tested and is theoretically slower since CryFS seems to employ an advanced algorithm to manage file blocks, while Bijou only uses basic data structures.

[hardcore-sushi]

RocksDB does not support encryption

OK but why not encrypt the values manually before storing them in the database, or simply use another database that supports encryption? I ask this question because I believe that software patching is generally a bad practice when developing open-source projects in the long run by a small team. And this stems from my experience: DroidFS actually uses 4 patched projects that I maintain myself next to.

The custom storage backend is a very interesting feature as it could allow DroidFS to work with remote volumes, for example with cloud providers applications.

[Mivik]

why not encrypt the values manually before storing them in the database

Firstly the encryption / decryption would then be too frequent and might impact the performance. Second, for storing directory structures in the database, there are two ways I can think of:

1. Serialize the whole directory structure (as a name -> ID map) in a single field. That would be easy to encrypt / decrypt (on each read and write) but requires decrypting the whole field before accessing a single entry, which can dramatically impact performance.
2. Store directory entries in subkey. For example, if the directory's ID is id and it has a child called data.txt, then the key id + "/data.txt" is used in the kv database to store the directory entry. This approach means you cannot simply use indeterministic encryption (i.e., with IV), and requires extra work and can allow attackers to rename files arbitrarily (which applies to gocryptfs).

Overall, simply encrypting the whole database stood out to me as the best approach.

I'd like to clarify a little bit about "patching". Theoretically speaking, I'm not patching RocksDB, but instead rust-rocksdb. RocksDB has many features that are intended to be used by implementing abstract classes, which is called Customizable Classes (TableFactory, MergeOperator, Env, etc.). Obviously, there's no way of doing them in pure Rust. What I did is implementing a customized Env in cpp, putting it in rust-rocksdb's source tree and adding a Rust interface. The only patched part is the building layer of rust-rocksdb, and should work as long as RocksDB's public interface does not change since it's outside of RocksDB's source tree. So yeah I don't think it's really a big deal.

[hardcore-sushi]

Okay, I see. This is more of an extension than a patch.

Overall, simply encrypting the whole database stood out to me as the best approach.

Sounds fair. But why didn't you choose to use a database that supports encryption natively, and possibly even one written in rust?

[Mivik]

In my view, the primary consideration when selecting a kv storage solution should not hinge on whether it supports encryption. According to this, RocksDB ranks among the top key-value stores and might even be the best embeddable key-value storage, given that other contenders seem non-embeddable, and that's simply the reason for my choosing it.

Furthermore, implementing encryption independently doesn't cost much, and grants us complete control over the encryption process (for instance, I used XSalsa from libsodium), offering potential benefits for future enhancements.

[hardcore-sushi]

Thanks for all these explanations.

At the moment, I don't have enough time to work on integrating Bijou into DroidFS, but it's something I'd like to see happen. First, do you succeed in building Bijou for the aarch64-linux-android target and using it under Android (as root for FUSE)? If so, would you like to open a PR at least for the JNI part? I think this should be directly implementable from Rust using the jni crate.

[Mivik]

Sure! I'll start working on it in a day or so. I've been quite busy recently :')