rencfs

[!WARNING]
This crate hasn't been audited; it's using ring crate, which is a well-known audited library, so in principle, at least the primitives should offer a similar level of security.
This is still under development. Please do not use it with sensitive data for now; please wait for a stable release.
It's mostly ideal for experimental and learning projects.

An encrypted file system written in Rust mounted with FUSE on Linux. It can be used to create encrypted directories.

You can then safely back up the encrypted directory to an untrusted server without worrying about the data being exposed. You can also store it in a cloud storage service like Google Drive, Dropbox, etc., and sync it across multiple devices.

You can use it as CLI or as a library to build your custom FUSE implementation or other apps that work with encrypted data.

Introduction

• Motivation Create a simple, performant, modular and ergonomic yet very secure encrypted filesystem to protect your privacy, which is also open source and is correctly and safely using well-known audited crates as cryptographic primitives.
• Read an article The Hitchhiker’s Guide to Building an Encrypted Filesystem in Rust.
• A one-pager The Hitchhiker’s Guide to Building an Encrypted Filesystem in Rust.
• Talks
  • The Hitchhiker’s Guide to Building an Encrypted Filesystem in Rust @meetup.com/star-tech-rd-reloaded and @OmniOpenCon.
  • Basics of cryptography, Authenticated Encryption, Rust in cryptography and how to build an encrypted filesystem @ITDays and slides.
• It was crate of the week in Aug 2024.

Key features

Some of these are still being worked on and marked with [WIP].

• Security using well-known audited AEAD cryptography primitives;
• [WIP] Data integrity, data is written with WAL to ensure integrity even on crash or power loss
• [WIP] Hide all info for enhanced privacy; all metadata, content, file name, file size, *time fields, files count, and directory structure is encrypted
• Safely manage credentials in memory with mlock(2), mprotect, zeroize, and expiry to mitigate cold boot attacks;
• Memory safety, performance, and optimized for concurrency with Rust;
• Simplicity;
• Encryption key generated from password;
• Password saved in OS's keyring;
• Change password without re-encrypting all data;
• [WIP] Generate unique nonce in offline mode
• [WIP] Add file inode and chunk index to AAD This prevents blocks from being copied between or within files by an attacker;
• Fast seek on both reads and writes;
• Writes in parallel;
• Exposed with FUSE;
• Fully concurrent for all operations;
• [WIP] Handle long file names
• [WIP] Abstraction layer for Rust File and fs API to use it as lib to switch to using encrypted files by just changing the use statements
• [WIP] Abstraction layer to access the storage with implementations for desktop, Wasm, Android, and iOS and the ability to write your own implementation

Alternatives

Implementation

• Functionality
• Stack

Documentation

• Docs

Please look into Flows for a detailed sequence flow description.

Usage and Development

• Usage
• Build from Source
• Minimum Supported Rust Version (MSRV). The minimum supported version is 1.75.

Next steps

• The plan is to implement it also on macOS and Windows
• Systemd service is being worked on rencfs-daemon
• GUI is being worked on rencfs-desktop and ciphershell-kotlin
• Mobile apps for Android and iOS are being worked on ciphershell-kotlin

Considerations

• Performance Aes256Gcm is slightly faster than ChaCha20Poly1305 by an average factor of 1.28. This is because of the hardware acceleration of AES on most CPUs via AES-NI. However, where hardware acceleration is unavailable, ChaCha20Poly1305 is faster. Also, ChaChaPoly1305 is better at SIMD.
• ⚠️ Security
• Cipher comparison
• Others

Contribute

If you find any issues or vulnerabilities or you'd like a feature, please follow these steps:

• Open a bug: Create a report to help us improve.
• Report a security vulnerability: Report a security vulnerability.
• Feature request: Suggest an idea for this project.

Feel free to fork, change, and use it however you want. We always appreciate it if you build something interesting and feel like sharing pull requests.

How to contribute:

• Please see CONTRIBUTING.md

Follow us

• Blog and tutorial There is a series of articles about the evolution of this project, trying to keep it like a tutorial. This is the first one.

Get in touch

• Slack
• hello@xorio.rs
• LinkedIn