rfjakob / gocryptfs

Encrypted overlay filesystem written in Go
https://nuetzlich.net/gocryptfs/
MIT License
3.51k stars 249 forks source link

question regarding GOCRYPTFS_BAD_NAME behavior in case of file content corruption #837

Closed nad0vs closed 4 months ago

nad0vs commented 6 months ago

Basically, when the file name was corrupted (or surreptitiously edited in-ciphertext without regard to it being a gocryptfs encrypted file) and the volume is mounted with

-badname '*'

the file would show up with GOCRYPTFS_BAD_NAME which is expected behavior and good.

However, am I correct in my understanding that if the file is corrupted more subtly (contents tampered directly in ciphertext, or some subtle file-system/drive fault) while name remains un-tampered, it is possible for the corrupted file to show up normally (without GOCRYPTFS_BAD_NAME tag) and simply contain gibberish (attempt to decrypt tampered content failure) ?

Reason for asking: I am contemplating options for faster, more practical corruption detection than the -fsck option.

the -fsck is not very useful for me :-) because the files I encrypt amount to a notch over 10 TB size-wise in total, and -fsck 'ing that mass takes basically forever, making it a not-very-practical routine checkup to put it mildly

rfjakob commented 4 months ago

it is possible for the corrupted file to show up normally (without GOCRYPTFS_BAD_NAME tag) and simply contain gibberish (attempt to decrypt tampered content failure) ?

Yes.