-
Notifications
You must be signed in to change notification settings - Fork 249
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Question] Encrypted backups without reverse mode possible? #848
Comments
I performed the following test: System 1 source:
System 2 backups system:
The data was readable. If this is in any way discouraged :
Please let me know. Thank you. |
Yes!
Yes! |
Reverse mode is for when the data is not already encrypted on disk. |
Thank you very much. Adding some extra information for future google searches and people that will lose eCryptfs kernel support in 2025. eCryptfs used the kernel keyring, You can potentially use the This is a quick proof of concept (Python could handle the passphrase insecurely in memory). But we can't depend on unmaintained
|
Every gocryptfs article about backup purposes is talking about reverse mode, as if there's no other option.
Let's say a user has
/home/username.cipherdir/
initialized (with standard options, no deterministic, no AES-SIV) and mounted at/home/username/
Exposing
/home/username/
in reverse mode (deterministic, AES-SIV) in/tmp/foobar/
to create backups of your home directory seems like twice the effort.Would it be possible to rsync copy
/home/username.cipherdir/
to your backups server directly, ignoring reverse mode entirely?If the answer is yes. Would it be possible to rsync copy
/home/username.cipherdir/
while it's actively mounted at/home/username/
so you don't have to unmount your $HOME every time a backup needs to run?P.S. This is how eCryptfs used to work, it allowed taking incremental rsync snapshots of the so called "lower" encrypted directory without special deterministic modes or unmounting your $HOME.
Thank you.
The text was updated successfully, but these errors were encountered: