Skip to content
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

Feature Request: Reverse mode same encrypted file hash independent from directory #402

Closed
kwinz opened this issue Jun 11, 2019 · 0 comments

Comments

@kwinz
Copy link

kwinz commented Jun 11, 2019

Hi,

I am using gocryptfs with reverse mode for its intended main purpose: storing an encrypted online backup.
Many online backup tools and also Dropbox calculate a hash of the file, or blocks of the file to check if it is already online, and if it is, doesn't reupload it again.
My use is that if I move a huge file from one directory to the other to organize my drive the hash of the encrypted file will stay the same and the huge file's encrypted counterpart is not reuploaded again.
However, if I understand the documentation correctly, the IV in reverse mode currently depends on the path of the file, so if I move a file, it is completely reuploaded.
Or if I back up a folder with say 20TB of files: file1, file2, file3,.... and later I want to reorganize it into topic1/file1, topic1/file2, topic2/file3, ... then I would have to reupload all 20TB, leading to multiple days or weeks where I don't have a current backup.
I would like the content encryption to only depend on the master-key derived from .gocryptfs.reverse.conf, and not the full path (perhaps the local filename part of the full path could still be used as IV).
If the only downside is that the backup provider can tell if I have the same file in multiple directories, then that's a perfectly fine tradeoff for me.

Is this possible today? Or how could it be implemented? Thank you in advance!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant