From b7be9ce06f1b46f032cd236c64b2fd16d989dd8b Mon Sep 17 00:00:00 2001 From: Radu Marias Date: Fri, 3 May 2024 21:39:36 +0300 Subject: [PATCH 01/13] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 7fba2000..89e1eba3 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ An encrypted file system that mounts with FUSE on Linux. It can be used to create encrypted directories. -It can then safely backup the encrypted folder on an untrusted server without worrying about the data being exposed.\ +You can then safely backup the encrypted folder on an untrusted server without worrying about the data being exposed.\ You can also store it in any cloud storage like Google Drive, Dropbox, etc. and have it synced across multiple devices. \ From f8979157125be433e8c6d79b01f4fea8643c1384 Mon Sep 17 00:00:00 2001 From: Radu Marias Date: Fri, 3 May 2024 21:57:03 +0300 Subject: [PATCH 02/13] Update README.md --- README.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 89e1eba3..c684d4d1 100644 --- a/README.md +++ b/README.md @@ -32,8 +32,7 @@ sudo apt-get update && sudo apt-get -y install fuse3 You can install the encrypted file system binary using the following command ```bash -yay -Syu -yay -S rencfs +yay -Syu && yay -S rencfs ``` ### Install with cargo @@ -175,4 +174,4 @@ cargo build --release ```bash cargo run -- --mount-point MOUNT_POINT --data-dir DATA_DIR -``` \ No newline at end of file +``` From 680e0c97e796c1526b4cd17950f8fab53112903e Mon Sep 17 00:00:00 2001 From: Radu Marias Date: Fri, 3 May 2024 23:42:19 +0300 Subject: [PATCH 03/13] Update README.md --- README.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/README.md b/README.md index c684d4d1..1e3e521c 100644 --- a/README.md +++ b/README.md @@ -11,6 +11,19 @@ You can also store it in any cloud storage like Google Drive, Dropbox, etc. and [![docs.rs](https://img.shields.io/docsrs/rencfs?label=docs.rs)](https://docs.rs/rencfs/) [![test](https://github.com/radumarias/rencfs/actions/workflows/test.yml/badge.svg)](https://github.com/radumarias/rencfs/actions/workflows/test.yml) + +# Functionality + +I keeps all encrypted data in a dedicated directory with files structured on inodes (with meta info), files for binary content and folders entries. All data and also filenames are encrypted + +# Stack + +- it's fully async built upon [tokio](https://crates.io/crates/tokio) and [fuse3](https://crates.io/crates/fuse3) +- [ring](https://crates.io/crates/ring) for encryption and [argon2](https://crates.io/crates/argon2) for key derivation function (creating encryption key from password) +- [secrecy](https://crates.io/crates/secrecy) for keeping pass and encryption keys safe in memory and zeroing them when not used. It keeps encryption keys in memory only while being used and when not active it will release and zeroing them from memory +- password can be saved in OS keyring using [keyring](https://crates.io/crates/keyring) +- [tracing](https://crates.io/crates/tracing) for logs + # Usage You can use it as a command line tool to mount an encrypted file system, or directly using the library to build your own binary (for library, you can follow the [documentation](https://docs.rs/rencfs/latest/rencfs/)). From eaff1db4d646f91694105bcea63946f7b313d141 Mon Sep 17 00:00:00 2001 From: Radu Marias Date: Fri, 3 May 2024 23:51:46 +0300 Subject: [PATCH 04/13] Update README.md --- README.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 1e3e521c..9a4fb7ab 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,7 @@ You can also store it in any cloud storage like Google Drive, Dropbox, etc. and # Functionality -I keeps all encrypted data in a dedicated directory with files structured on inodes (with meta info), files for binary content and folders entries. All data and also filenames are encrypted +I keeps all encrypted data in a dedicated directory with files structured on inodes (with meta info), files for binary content and folders entries. All data and also filenames are encrypted. For new files it generates inode number randomly in `u64` space so it reduces the chance of conflicts when used offline and synced later. Password is collected from CLI and can pe saved in OS keyring # Stack @@ -188,3 +188,14 @@ cargo build --release ```bash cargo run -- --mount-point MOUNT_POINT --data-dir DATA_DIR ``` + +# Future + +- Plan is to implement it also on macOS and Windows +- A systemd service is being worked on [rencfs-daemon](https://github.com/radumarias/rencfs-daemon +- A GUI is on the way [rencfs_desktop](https://github.com/radumarias/rencfs_desktop) +- Mobile apps for Android and iOS are on the way + +# Contribution + +Feel free to fork it and change it the way you want. If you build something interesting and feel to share pull requests are always apporeciated From 624d156a02a726bc22d05f266851027d040adc9b Mon Sep 17 00:00:00 2001 From: Radu Marias Date: Fri, 3 May 2024 23:55:00 +0300 Subject: [PATCH 05/13] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 9a4fb7ab..446c380d 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,7 @@ You can also store it in any cloud storage like Google Drive, Dropbox, etc. and # Functionality -I keeps all encrypted data in a dedicated directory with files structured on inodes (with meta info), files for binary content and folders entries. All data and also filenames are encrypted. For new files it generates inode number randomly in `u64` space so it reduces the chance of conflicts when used offline and synced later. Password is collected from CLI and can pe saved in OS keyring +I keeps all encrypted data and encryption key in a dedicated directory with files structured on inodes (with meta info), files for binary content and directories with files/directories entries. All data, metadata and also filenames are encrypted. For new files it generates inode number randomly in `u64` space so it reduces the chance of conflicts when used offline and synced later. Password is collected from CLI and can pe saved in OS keyring # Stack From 7c3507f5c9151baa8576ea9503027edafa45d974 Mon Sep 17 00:00:00 2001 From: Radu Marias Date: Sat, 4 May 2024 10:56:23 +0300 Subject: [PATCH 06/13] Update README.md --- README.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 446c380d..f2275fb9 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,10 @@ You can also store it in any cloud storage like Google Drive, Dropbox, etc. and # Functionality -I keeps all encrypted data and encryption key in a dedicated directory with files structured on inodes (with meta info), files for binary content and directories with files/directories entries. All data, metadata and also filenames are encrypted. For new files it generates inode number randomly in `u64` space so it reduces the chance of conflicts when used offline and synced later. Password is collected from CLI and can pe saved in OS keyring +I keeps all encrypted data and encryption key in a dedicated directory with files structured on inodes (with meta info), files for binary content and directories with files/directories entries. All data, metadata and also filenames are encrypted. For new files it generates inode number randomly in `u64` space so it reduces the chance of conflicts when used offline and synced later. + +Password is collected from CLI and can be saved in OS keyring. +Encryption key is also encrypted with another key derived from the password. This gives the ability to change the password without re-encrypting all data, we just re-encrypt the key. # Stack From f4b8c518d1140886fcc2cdc544fa1f510a4b5cb6 Mon Sep 17 00:00:00 2001 From: Radu Marias Date: Sat, 4 May 2024 10:58:27 +0300 Subject: [PATCH 07/13] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index f2275fb9..0fea91ab 100644 --- a/README.md +++ b/README.md @@ -22,7 +22,7 @@ Encryption key is also encrypted with another key derived from the password. Thi # Stack - it's fully async built upon [tokio](https://crates.io/crates/tokio) and [fuse3](https://crates.io/crates/fuse3) -- [ring](https://crates.io/crates/ring) for encryption and [argon2](https://crates.io/crates/argon2) for key derivation function (creating encryption key from password) +- [ring](https://crates.io/crates/ring) for encryption and [argon2](https://crates.io/crates/argon2) for key derivation function (creating key used to encrypt master encryption key from password) - [secrecy](https://crates.io/crates/secrecy) for keeping pass and encryption keys safe in memory and zeroing them when not used. It keeps encryption keys in memory only while being used and when not active it will release and zeroing them from memory - password can be saved in OS keyring using [keyring](https://crates.io/crates/keyring) - [tracing](https://crates.io/crates/tracing) for logs From 33cdbaaf3b2b5913bf135383c0201bbec0d9a989 Mon Sep 17 00:00:00 2001 From: Radu Marias Date: Sat, 4 May 2024 22:57:35 +0300 Subject: [PATCH 08/13] Update README.md --- README.md | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 0fea91ab..b72174f7 100644 --- a/README.md +++ b/README.md @@ -14,11 +14,19 @@ You can also store it in any cloud storage like Google Drive, Dropbox, etc. and # Functionality -I keeps all encrypted data and encryption key in a dedicated directory with files structured on inodes (with meta info), files for binary content and directories with files/directories entries. All data, metadata and also filenames are encrypted. For new files it generates inode number randomly in `u64` space so it reduces the chance of conflicts when used offline and synced later. +I keeps all encrypted data and master encryption key in a dedicated directory with files structured on inodes (with meta info), files for binary content and directories with files/directories entries. All data, metadata and also filenames are encrypted. For new files it generates inode number randomly in `u64` space so it reduces the chance of conflicts when used offline and synced later. Password is collected from CLI and can be saved in OS keyring. Encryption key is also encrypted with another key derived from the password. This gives the ability to change the password without re-encrypting all data, we just re-encrypt the key. +# Implementation + +- Safety on process kill (or crash): all writes to encrypted content is done in a tmp file and them using `mv` to move to destination. the `mv` operation is atomic as it's using `rename()` which is atomic as per specs, see [here](https://pubs.opengroup.org/onlinepubs/009695399/functions/rename.html) `That specification requires that the action of the function be atomic.`. +- Phantom reads: reading older content from a file, this is not possible. While writing, data is kept in a buffer and tmp file and on flushing that buffer we write the new content to the file (as per above the tmp file is moved into place with `mv`). After that we reset all opened readers so any reads after that will pickup the new content. +- What kind of metadata does it leak: close to none. The filename, actual file size and other file attrs (times, permissions, other flags) are kept encrypted. What it could possible leak is the following + - If a directory has children we keep those children in a directory with name as inode numiber with encrypted names as file entries in it. So we could see how many children a directory has, but we can't identify that actual directory name, we can just see it's inode number (internal representation like an id for each file) and we cannot see the actual filenames or directory or children. + - Each file content is saved in a separate file so we could see the size of the encrypted content, but not the actual filesize. + # Stack - it's fully async built upon [tokio](https://crates.io/crates/tokio) and [fuse3](https://crates.io/crates/fuse3) @@ -27,6 +35,11 @@ Encryption key is also encrypted with another key derived from the password. Thi - password can be saved in OS keyring using [keyring](https://crates.io/crates/keyring) - [tracing](https://crates.io/crates/tracing) for logs +# Considerations + +It doesn't have any independent review from experts, but if the project gains any traction would think about doing that. +Please note, this project doesn't try to reinvent the wheel or be better than already proven implementations. It started as a learning project of Rust programming language and I feel like keep building more on it. It's a fairly simple and standard implementation that tries to respect all security standards, use safe libs and ciphers in the implementation so that it can be extended from this. Indeed it doesn't have the maturity yet to "fight" other well known implementations but it can be a project from which others can learn or build upon or why not for some to actually use it keeping in mind all the above. + # Usage You can use it as a command line tool to mount an encrypted file system, or directly using the library to build your own binary (for library, you can follow the [documentation](https://docs.rs/rencfs/latest/rencfs/)). @@ -195,10 +208,10 @@ cargo run -- --mount-point MOUNT_POINT --data-dir DATA_DIR # Future - Plan is to implement it also on macOS and Windows -- A systemd service is being worked on [rencfs-daemon](https://github.com/radumarias/rencfs-daemon +- A systemd service is being worked on [rencfs-daemon](https://github.com/radumarias/rencfs-daemon) - A GUI is on the way [rencfs_desktop](https://github.com/radumarias/rencfs_desktop) - Mobile apps for Android and iOS are on the way # Contribution -Feel free to fork it and change it the way you want. If you build something interesting and feel to share pull requests are always apporeciated +Feel free to fork it, change and use it in any way that you want. If you build something interesting and feel like sharing pull requests are always apporeciated. From 30624852065629fe75d889e517c3af2ae4e26afd Mon Sep 17 00:00:00 2001 From: Radu Marias Date: Sat, 4 May 2024 22:58:32 +0300 Subject: [PATCH 09/13] Update README.md --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index b72174f7..80f0af5d 100644 --- a/README.md +++ b/README.md @@ -35,11 +35,6 @@ Encryption key is also encrypted with another key derived from the password. Thi - password can be saved in OS keyring using [keyring](https://crates.io/crates/keyring) - [tracing](https://crates.io/crates/tracing) for logs -# Considerations - -It doesn't have any independent review from experts, but if the project gains any traction would think about doing that. -Please note, this project doesn't try to reinvent the wheel or be better than already proven implementations. It started as a learning project of Rust programming language and I feel like keep building more on it. It's a fairly simple and standard implementation that tries to respect all security standards, use safe libs and ciphers in the implementation so that it can be extended from this. Indeed it doesn't have the maturity yet to "fight" other well known implementations but it can be a project from which others can learn or build upon or why not for some to actually use it keeping in mind all the above. - # Usage You can use it as a command line tool to mount an encrypted file system, or directly using the library to build your own binary (for library, you can follow the [documentation](https://docs.rs/rencfs/latest/rencfs/)). @@ -215,3 +210,8 @@ cargo run -- --mount-point MOUNT_POINT --data-dir DATA_DIR # Contribution Feel free to fork it, change and use it in any way that you want. If you build something interesting and feel like sharing pull requests are always apporeciated. + +# Considerations + +It doesn't have any independent review from experts, but if the project gains any traction would think about doing that. +Please note, this project doesn't try to reinvent the wheel or be better than already proven implementations. It started as a learning project of Rust programming language and I feel like keep building more on it. It's a fairly simple and standard implementation that tries to respect all security standards, use safe libs and ciphers in the implementation so that it can be extended from this. Indeed it doesn't have the maturity yet to "fight" other well known implementations but it can be a project from which others can learn or build upon or why not for some to actually use it keeping in mind all the above. From 3db3346d53ceac6ea308b1f1e76bcdeaf46b3134 Mon Sep 17 00:00:00 2001 From: Radu Marias Date: Sat, 4 May 2024 22:59:11 +0300 Subject: [PATCH 10/13] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 80f0af5d..a64c853c 100644 --- a/README.md +++ b/README.md @@ -21,7 +21,7 @@ Encryption key is also encrypted with another key derived from the password. Thi # Implementation -- Safety on process kill (or crash): all writes to encrypted content is done in a tmp file and them using `mv` to move to destination. the `mv` operation is atomic as it's using `rename()` which is atomic as per specs, see [here](https://pubs.opengroup.org/onlinepubs/009695399/functions/rename.html) `That specification requires that the action of the function be atomic.`. +- Safety on process kill (or crash): all writes to encrypted content is done in a tmp file and them using `mv` to move to destination. the `mv` operation is atomic as it's using `rename()` which is atomic as per specs, see [here](https://pubs.opengroup.org/onlinepubs/009695399/functions/rename.html) `That specification requires that the action of the function be atomic.` - Phantom reads: reading older content from a file, this is not possible. While writing, data is kept in a buffer and tmp file and on flushing that buffer we write the new content to the file (as per above the tmp file is moved into place with `mv`). After that we reset all opened readers so any reads after that will pickup the new content. - What kind of metadata does it leak: close to none. The filename, actual file size and other file attrs (times, permissions, other flags) are kept encrypted. What it could possible leak is the following - If a directory has children we keep those children in a directory with name as inode numiber with encrypted names as file entries in it. So we could see how many children a directory has, but we can't identify that actual directory name, we can just see it's inode number (internal representation like an id for each file) and we cannot see the actual filenames or directory or children. From 1de0211c73424d87438a3bd14a9d23c3524799ae Mon Sep 17 00:00:00 2001 From: Radu Marias Date: Sat, 4 May 2024 23:00:13 +0300 Subject: [PATCH 11/13] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index a64c853c..663baf14 100644 --- a/README.md +++ b/README.md @@ -24,7 +24,7 @@ Encryption key is also encrypted with another key derived from the password. Thi - Safety on process kill (or crash): all writes to encrypted content is done in a tmp file and them using `mv` to move to destination. the `mv` operation is atomic as it's using `rename()` which is atomic as per specs, see [here](https://pubs.opengroup.org/onlinepubs/009695399/functions/rename.html) `That specification requires that the action of the function be atomic.` - Phantom reads: reading older content from a file, this is not possible. While writing, data is kept in a buffer and tmp file and on flushing that buffer we write the new content to the file (as per above the tmp file is moved into place with `mv`). After that we reset all opened readers so any reads after that will pickup the new content. - What kind of metadata does it leak: close to none. The filename, actual file size and other file attrs (times, permissions, other flags) are kept encrypted. What it could possible leak is the following - - If a directory has children we keep those children in a directory with name as inode numiber with encrypted names as file entries in it. So we could see how many children a directory has, but we can't identify that actual directory name, we can just see it's inode number (internal representation like an id for each file) and we cannot see the actual filenames or directory or children. + - If a directory has children we keep those children in a directory with name as inode numiber with encrypted names of children as file in it. So we could see how many children a directory has, but we can't identify that actual directory name, we can just see it's inode number (internal representation like an id for each file) and we cannot see the actual filenames or directory or children. - Each file content is saved in a separate file so we could see the size of the encrypted content, but not the actual filesize. # Stack From bbacc1c62107b0b3f66e60ec4207b3289e501740 Mon Sep 17 00:00:00 2001 From: Radu Marias Date: Sat, 4 May 2024 23:00:39 +0300 Subject: [PATCH 12/13] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 663baf14..8c323b95 100644 --- a/README.md +++ b/README.md @@ -24,7 +24,7 @@ Encryption key is also encrypted with another key derived from the password. Thi - Safety on process kill (or crash): all writes to encrypted content is done in a tmp file and them using `mv` to move to destination. the `mv` operation is atomic as it's using `rename()` which is atomic as per specs, see [here](https://pubs.opengroup.org/onlinepubs/009695399/functions/rename.html) `That specification requires that the action of the function be atomic.` - Phantom reads: reading older content from a file, this is not possible. While writing, data is kept in a buffer and tmp file and on flushing that buffer we write the new content to the file (as per above the tmp file is moved into place with `mv`). After that we reset all opened readers so any reads after that will pickup the new content. - What kind of metadata does it leak: close to none. The filename, actual file size and other file attrs (times, permissions, other flags) are kept encrypted. What it could possible leak is the following - - If a directory has children we keep those children in a directory with name as inode numiber with encrypted names of children as file in it. So we could see how many children a directory has, but we can't identify that actual directory name, we can just see it's inode number (internal representation like an id for each file) and we cannot see the actual filenames or directory or children. + - If a directory has children we keep those children in a directory with name as inode numiber with encrypted names of children as files in it. So we could see how many children a directory has, but we can't identify that actual directory name, we can just see it's inode number (internal representation like an id for each file) and we cannot see the actual filenames or directory or children. - Each file content is saved in a separate file so we could see the size of the encrypted content, but not the actual filesize. # Stack From e228082cc7f62181b25b170331f0c9b34ae079a4 Mon Sep 17 00:00:00 2001 From: Radu Marias Date: Sun, 5 May 2024 00:34:06 +0300 Subject: [PATCH 13/13] Update README.md --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 8c323b95..cc36d0fe 100644 --- a/README.md +++ b/README.md @@ -31,6 +31,7 @@ Encryption key is also encrypted with another key derived from the password. Thi - it's fully async built upon [tokio](https://crates.io/crates/tokio) and [fuse3](https://crates.io/crates/fuse3) - [ring](https://crates.io/crates/ring) for encryption and [argon2](https://crates.io/crates/argon2) for key derivation function (creating key used to encrypt master encryption key from password) +- [rand_chacha](https://crates.io/crates/rand_chacha) for random generators - [secrecy](https://crates.io/crates/secrecy) for keeping pass and encryption keys safe in memory and zeroing them when not used. It keeps encryption keys in memory only while being used and when not active it will release and zeroing them from memory - password can be saved in OS keyring using [keyring](https://crates.io/crates/keyring) - [tracing](https://crates.io/crates/tracing) for logs