Open slackner opened 5 years ago
For (1), I wonder if it would be better to drop the IV (or use all zeros) for files that have hard links. As reverse mode uses AES-SIV, having unique IVs is not critical.
I don't think that would be better. In fact, it would make it even easier for an attacker to mess with a backup, when all hardlinked files use the same IV.
For (1) my proposed solution would be to derive the IV directly from the inode number, which is the same, no matter which path is used. However, that would not really solve the second problem. And it would mean that creating a hardlink at some later time also causes a full retransmit of the file.
What also would be an option: Drop the whole inodeTable
logic, and instead generate unique inode numbers. Then the content is transferred multiple times, but at least it is fully deterministic, and does not depend on the access order of files/directories.
derive the IV directly from the inode number
The problem here is when you move your data to a new filesystem (user gets a bigger hdd for example), all the encrypted content changes.
This issue already exists for quite some time, but I don't think there is a bug report for it yet. I was initially hoping to fix it together with #158, but since we haven't come up with a good solution for that one yet, I'm opening this as a separate bug report.
In reverse mode, all inodes with
Nlink > 1
are tracked in a mapinodeTable
. The map is never cleared, and not preserved across restarts ofgocryptfs
. This logic can lead to several unexpected side-effects:(1) Assume the source directory contains two files referencing the same inode, then the encrypted file content depends on which path is accessed first after
gocryptfs
is started. Depending on the backup software this could be completely random (e.g., if multiple threads are used to enumerate the directory content), and could cause frequent retransmits. rsync is also affected when--checksum
is used.(2) Assume a file is deleted, and some time later (without restarting gocryptfs) a new file is created, which has the same inode number. Since
gocryptfs
never clears theinodeTable
, the new file reuses the initialization vectors of the previous file, even when it is located at a completely different location.