Symmetric Encryption

[Shadow53]

There is a little bit of configuration support for this already, but no actual support.

Essentially, backed up files will get encrypted using a given password, and restored files will be decrypted by the same.

There will be two sources of password: a raw password password = "" and a password command to retrieve it from somewhere else.

I'll need to do research into the best encryption to use for both speed and security. AES, probably.

[Shadow53]

I've been doing some research into algorithms that could be used, and here's the gist of what I've found:

• The two most common encryption methods are AES-GCM and ChaCha20/Poly1305
• AES is probably the most performant on modern x86 hardware because of AES-NI processor instructions
• When using software implementations, ChaCha20 is generally much faster and more likely to be secure from timing attacks
• Google is using ChaCha for TLS 1.3 stuff because it is better for mobile devices, which generally do not have hardware-accelerated AES
• XChaCha20/Poly1305 is a newer variant on ChaCha20/Poly1305 that has better security for reasons that made sense when I read them and have since disappeared from my brain.
• AES-SIV-GCM is a variant on AES-GCM that is a bit slower but is more resistant to nonce reuse.

So, without being an expert in cryptography, the best options appear to come down to:

• XChaCha20/Poly1305
• AES-SIV-GCM

... probably in that order, though that depends on what libraries are available for Rust, whether they've been verified, and so on.

[Shadow53]

Looks like RustCrypto has implementations of both with some amount of auditing for both -- the ChaCha crate was directly audited and the AES-SIV-GCM one was not, though its dependency crate for AES-GCM was.

[Shadow53]

Okay, so I've done a lot of research and I have determined what seems to be at least an okay route to go, if not good. This is regardless of which algorithm is used.

1. Whatever algorithm is used will need nonces. When it comes to hoard, the best options are going to be randomly generated or using a hash of the plaintext,
   • The latter would make the Operations check easier to do, but leaks data about the plaintext.
   • Nonces do not need to be secret, so storing them on disk is fine.
2. Using a random salt for each operation is a good idea, to help prevent (key, nonce) reuse. Using a cryptographically secure PRNG is important for this.
3. Looks like PBKDF2 is the standard for deriving a key from a password, so we should use that.
4. Can still perform the various checks, just with more effort.
   • The log files will store the encrypted path, with salt/nonce
   • To perform the checks, decrypt the paths, encrypt files on disk if needed, then do whatever comparisons
     • This will lead to encrypting files multiple times with different salts. Not sure there is a way around this without sacrificing security.
   • If decryption fails at any point, log a warning/error and abort