new encryption

This commit is contained in:
fyears
2024-03-25 00:21:56 +08:00
parent 6825241071
commit e283efc8f7
25 changed files with 725 additions and 58 deletions
+8
View File
@@ -0,0 +1,8 @@
# Encryption
Currently (March 2024), Remotely Save supports two end to end encryption format:
1. [RClone Crypt](./rclone.md) format, which is the recommend way now.
2. [OpenSSL enc](./openssl.md) format
Here is also the [comparation](./comparation.md).
+23
View File
@@ -0,0 +1,23 @@
# Comparation Between Encryption Formats
## Warning
**ALWAYS BACKUP YOUR VAULT MANUALLY!!!**
If you switch between RClone Crypt format and OpenSSL enc format, you have to delete the cloud vault files **manually** and **fully**, so that the plugin can re-sync (i.e. re-upload) the newly encrypted versions to the cloud.
## The feature table
| | RClone Crypt | OpenSSL enc | comments |
| ------------------------ | ------------------------------------------------------------------------------------------ | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| key generation | scrypt with fixed salt | PBKDF2 with dynamic salt | scrypt is better than PBKDF2 from the algorithm aspect. But RClone uses fixed salt by default. Also the parameters might affect the result. |
| content encryption | XSalsa20Poly1305 on chunks | AES-256-CBC | XSalsa20Poly1305 is way better than AES-256-CBC. And encryption by chunks should require less resources. |
| file name encryption | EME on each segment of the path | AES-256-CBC on the whole path | RClone has the benefit as well as pitfall that the path structure is preserved. Maybe it's more of a design decision difference? No comment on EME and AES-256-CBC. |
| viewing decrypted result | RClone has command that can mount the encrypted vault as if the encryption is transparent. | No convenient way except writing some scripts we are aware of. | RClone is way more convenient. |
## Some notes
1. Anyway, security is a hard problem. The author of Remotely Save doesn't have sufficient knowledge to "judge" which one is the better format. **Use them at your own risk.**
2. Currently the RClone Crypt format is recommended by default in Remotely Save. Just because of the taste from the Remotely Save author, who likes RClone.
3. **Always use a long password.**
4. Both algorithms are selected deliberately to **be compatible with some well-known third-party tools** (instead of some home-made methods) and **have many tests to ensure the correctness**.
@@ -1,10 +1,22 @@
# Encryption
# OpenSSL enc format
If a password is set, the files are encrypted before being sent to the cloud.
The encryption algorithm is delibrately designed to be aligned with openssl format.
## Warning
1. The encryption algorithm is implemented using web-crypto.
**ALWAYS BACKUP YOUR VAULT MANUALLY!!!**
If you switch between RClone Crypt format and OpenSSL enc format, you have to delete the cloud vault files **manually** and **fully**, so that the plugin can re-sync (i.e. re-upload) the newly encrypted versions to the cloud.
## Comparation between encryption formats
See the doc [Comparation](./comparation.md).
## Interoperability with official OpenSSL
This encryption algorithm is delibrately designed to be aligned with openssl format.
1. The encryption algorithm is implemented using web-crypto. Using AES-256-CBC.
2. The file content is encrypted using openssl format. Assuming a file named `sometext.txt`, a password `somepassword`, then the encryption is equivalent to the following command:
```bash
+46
View File
@@ -0,0 +1,46 @@
# RClone Crypt format
The encryption is compatible with RClone Crypt with **base64** name encryption format.
It's developed based on another js project by the same author of Remotely Save: [`@fyears/rclone-crypt`](https://github.com/fyears/rclone-crypt), which is NOT an official library from RClone, and is NOT affiliated with RClone.
Reasonable tests are also ported from official RClone code, to ensure the compatibility and correctness of the encryption.
## Warning
**ALWAYS BACKUP YOUR VAULT MANUALLY!!!**
If you switch between RClone Crypt format and OpenSSL enc format, you have to delete the cloud vault files **manually** and **fully**, so that the plugin can re-sync (i.e. re-upload) the newly encrypted versions to the cloud.
## Comparation between encryption formats
See the doc [Comparation](./comparation.md).
## Interoperability with official RClone
Please pay attention that the plugin uses **base64** of encrypted file names, while official RClone by default uses **base32** file names. The intention is purely for potentially support longer file names.
You could set up the RClone profile by calling `rclone config`. You need to create two profiles, one for your original connection and the other for RClone Crypt.
Finally, a working config file should like this:
```ini
[webdav1]
type = webdav
url = https://example.com/sharefolder1/subfolder1 # the same as the web address in Remotely Save settings.
vendor = other
user = <some webdav username>
pass = <some webdav password, obfuscated>
[webdav1crypt]
type = crypt
remote = nas1test:vaultname # the same as your "Remote Base Directory" (usually the vault name) in Remotely Save settings
password = <some encryption password, obfuscated>
filename_encoding = base64 # don't forget this!!!
```
You can use the `mount` command to view and see the files in file explorer! On Windows, the command should like this (the remote vault is mounted to drive `X:`):
```bash
rclone mount webdav1crypt: X: --network-mode
```
+1
View File
@@ -11,3 +11,4 @@
- [x] sync direction: incremental pull only
- [x] sync protection: warning based on the threshold
- [ ] partial sync: better sync on save
- [x] encrpytion: new encryption method, see [this](../../encryption/)