Explanation of Meta-File Generation about securefs HOT 2 CLOSED

Other crypto filesystems do not defend against the attack of replacement of a certain block with its old revision. The meta file ensures the integrity of the whole file and protects against such attacks. If you are not that paranoid, you can just create securefs format v4, which has substantially lower overhead.

I don't understand your last paragraph. The sizes of the meta file is a fraction of the content file, so if you have to redownload meta files every time, what do you do with the much larger content files?

As for the block size, there is no security implications of enlarging it. The only downside is that even when you request a read/write of very small size, securefs still have to read/write and decrypt/encrypt a whole block, so the larger the block size, the more wasted computation.

from securefs.

Perhaps it was badly worded. What happens is that Google's File Stream will download the meta file when opening the encrypted files via Windows Explorer, without opening the content. My assumption is that the data necessary for it to populate the file's metadata are present in the .meta file, hence the load.

In regards to storage, it means that even browsing through the folders with large files will download multiple meta files, even if the content files are never opened.

In any case, I can see the benefit of this method for encryption and the question has been answered, so I'll close the issue. Thanks!

from securefs.