Better alternatives for data encryption

[vicaya]

The current data at rest encryption design with RSA private key is both slow and insecure (crackable passphrase and not quantum safe, which is esp. problematic for data at rest). Go standard lib already deprecated RSA with passphrase. We had to explicitly suppress the compiler warning against the usage.

IMO. the following are reasonable alternatives:

1. Use the symmetric AES-GCM instead of RSA as the KEK (key encryption key) algo with a key derived from a robust KDF, e.g. argon2id (part of go standard library). The change is easy and small. It's sufficient for personal and test deployment, where passphrases can be used.
2. Use TOTP (and maybe other MFAs) authenticated remote secret server (suggest https://github.com/openbao/openbao, the current open source fork of hashicorp vault for cloud vendor independence) for managing KEK, similar to CMEK with KMS in cloud vendors. This is slightly more complex but still fairly straightforward. This is the preferred solution for production deployment, as only short-lived credential is exposed in multiple client nodes.

[solracsf]

Also related: #5174

JuiceFS could learn from Restic encryption (alsor programmed in Go): https://restic.readthedocs.io/en/v0.4.0/Design/

[vicaya]

Restic format is already "legacy", which uses scrypt for kdf, which is a second choice after argon2id according to OWASP, AES-CTR with Poly1305-AES is also "legacy" with less support compared with AES-256-GCM or xChaCha20-Poly1305

cf. https://soatok.blog/2020/07/12/comparison-of-symmetric-encryption-methods/

[davies]

Sounds, can you send PR for these?

[ab-shrek]

Can i take this up if no one is working on it?

[davies]

Can i take this up if no one is working on it?

Sure, no one is working on this

[vivekcode101]

Hey @ab-shrek are you still working on the issue?

[ab-shrek]

Hey @vivekcode101 I am not working on this. Feel free to take it up