InodeTable in reverse mode can lead to IV changes and reuse of IVs

[slackner]

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 map inodeTable. The map is never cleared, and not preserved across restarts of gocryptfs. 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 the inodeTable, the new file reuses the initialization vectors of the previous file, even when it is located at a completely different location.

[rfjakob]

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.

[slackner]

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.

[slackner]

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.

[rfjakob]

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.