Replies: 1 comment
-
|
Interesting find. I would have expected the Due to these coincidences it's possible to recursively re-generate the This also leads to the |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I was just playing around with this and didn't see it documented anywhere, so I figured posting here might help someone:
If you have an encrypted backup of your files created using the
reverseoption (I believe this implies feature flagsDirIVandAESSIVamong others), you have lost your original plaintext files, and for some reason yourgocryptfs.dirivfiles are missing from the encrypted backup, you can still recover their filenames.recovered,recovered-enc,backup,backup-decryptedgocryptfs.dirivare missing) intobackuprecoveredtorecovered-encrecovered-enc/gocryptfs.dirivtobackup/backuptobackup-decryptedbackup-decrypted(i.e., your original folder names) inrecoveredrecovered-encappear with the same name as one inbackupgocryptfs.dirivfile from that encrypted folder inrecovered-enc/<encrypted_folder>/gocryptfs.dirivtobackup/<encrypted_folder>/backup-decryptedAll filenames should be recoverable this way.
My feature request to the authors: (assuming I didn't miss such an option) it would be great if we could "regenerate" such
gocryptfs.dirivfiles from a "broken" (i.e., missinggocryptfs.dirivfiles) backup of a reverse mount natively from withingocryptfs(or some helper tool).I suppose at that point the question becomes: Why do the
gocryptfs.dirivfiles even exist for a reverse mount? If it's possible to recover the original filenames with just the config + password, what additional security do they provide? Is it just for performance reasons?Beta Was this translation helpful? Give feedback.
All reactions