new encryption
This commit is contained in:
fyears
@@ -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).
|
||||
@@ -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**.
|
||||
@@ -0,0 +1,46 @@
|
||||
# OpenSSL enc format
|
||||
|
||||
If a password is set, the files are encrypted before being sent to the cloud.
|
||||
|
||||
## 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 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
|
||||
# file content encryption (ignoring file path encryption)
|
||||
openssl enc -p -aes-256-cbc -pbkdf2 -iter 20000 -pass pass:somepassword -in ./sometext.txt -out ./sometext.txt.enc
|
||||
|
||||
# file content decryption (ignoring file path decryption)
|
||||
openssl enc -d -p -aes-256-cbc -pbkdf2 -iter 20000 -pass pass:somepassword -in ./sometext.txt.enc -out ./sometext.txt
|
||||
```
|
||||
|
||||
3. The file/directory path strings, are encrypted using openssl in binary mode and then `base64url without padding` is applied.
|
||||
Assuming the file path is `a-folder-文件夹/a-file-文件.md`, then the following commands are equivilent:
|
||||
|
||||
```bash
|
||||
# prepare the functions
|
||||
# https://unix.stackexchange.com/questions/628842
|
||||
base64url::encode () { base64 -w0 | tr '+/' '-_' | tr -d '='; }
|
||||
base64url::decode () { awk '{ if (length($0) % 4 == 3) print $0"="; else if (length($0) % 4 == 2) print $0"=="; else print $0; }' | tr -- '-_' '+/' | base64 -d; }
|
||||
|
||||
# pure string encryption then base32
|
||||
echo -n 'a-folder-文件夹/a-file-文件.md' | openssl enc -aes-256-cbc -pbkdf2 -iter 20000 -pass pass:mylongpassword | base64url::encode
|
||||
|
||||
# pure string base64url then decryption
|
||||
echo -n 'U2FsdGVkX19tNkdFL5rZeHxbe7FL-Pp5mkZJkDNFJWFT6lldZlfa57j0C_cKn0I3PZ9YDvOkyoKqfF6lbn0_yg' | base64url::decode | openssl enc -d -aes-256-cbc -pbkdf2 -iter 20000 -pass pass:mylongpassword
|
||||
```
|
||||
|
||||
4. The directory is considered as special "0-byte" object on remote s3. So this meta infomation may be easily guessed if some third party can access the remote bucket.
|
||||
@@ -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
|
||||
```
|
||||
Reference in New Issue
Block a user