1

I am planning to set up a NAS with ecryptfs used for encryption. I am wondering if ecryptfs will tell me if a file has been silently corrupted (by e.g., a faulty harddrive), or if I would still be dependent on the underlying filesystem to do data checksumming for me?

I may use btrfs as the underlying filesystem anyway to get the snapshot feature, but I would still be interested to know if for example ext4 + ecryptfs would provide the same guarantees agains hidden file corruptions as plain btrfs (or btrfs + ecrypts) would, because of the checksumming features of btrfs.

Quantumboredom
  • 113
  • 4

2 Answers2

2

The above answer is incorrect. The actual implementation of eCryptFS does not checksum data by default or at all. Simple demonstration:

$ mkdir /tmp/front /tmp/back
$ sudo mount -o key=passphrase:passwd=Test,ecryptfs_hmac,ecryptfs_enable_filename_crypto=no,ecryptfs_passthrough=no,ecryptfs_unlink_sigs,ecryptfs_key_bytes=16,ecryptfs_cipher=aes -t ecryptfs /tmp/back/ /tmp/front/
$ echo HelloWorld > /tmp/front/HelloWorld.txt
$ cat /tmp/front/HelloWorld.txt
HelloWorld
$ sudo umount /tmp/front
$ printf "deadbeaf" | dd  of=/tmp/back/HelloWorld.txt  bs=1 seek=8192 count=8 conv=notrunc
$ sudo mount -o key=passphrase:passwd=Test,ecryptfs_hmac,ecryptfs_enable_filename_crypto=no,ecryptfs_passthrough=no,ecryptfs_unlink_sigs,ecryptfs_key_bytes=16,ecryptfs_cipher=aes -t ecryptfs /tmp/back/ /tmp/front/
$ cat /tmp/front/HelloWorld.txt
<garbage>

Also:

$ ecryptfs-stat /tmp/back/HelloWorld.txt 
File version: [3]
Decrypted file size: [11]
Number of header bytes at front of file: [8192]
Metadata in the header region
Encrypted
HMAC disabled

eCryptfs does not give a read error or any indication that anything is wrong. Note that this is even with the ecryptfs_hmac option, which is supposed to enabled checksumming, but apparently doesn't. The actual source code of ecryptfs does contain HMAC code, so I am not sure why that isn't working. Quick Google search indicates that HMAC code might be incomplete. Haven't yet looked deeper into it.

Grumbel
  • 194
  • 1
  • 8
1

eCryptFS does checksum data. There's a paper that describes how eCryptFS works. One of the things eCryptFS does is protect against tampering of the file by adversaries, and to do that it computes a HMAC and stores it with the encrypted file. As a bonus, this obviously also protects against accidental "tampering," such as by cosmic rays, electronic noise, or simple wear-and-tear (collectively described by bit rot).

However, btrfs does one additional thing that I'm sure eCryptFS does not do: mirroring/replication and parity. With mirroring (RAID1) or parity (RAID5 or RAID6), btrfs is able to automatically find a good copy of a piece of file should it detect corruption with the piece currently being read. Ars Technica has a very good article on corruption and how to best utilize the feature of btrfs or ZFS to keep data safe.

If you go with ext4 and eCryptFS, at best you would only know that something was corrupt or tampered with, but you'd have to manually intervene to deal with the problem. I would recommend sticking with btrfs and eCryptFS, which provides both checksumming (as long as you do not disable copy-on-write) and can also maintain redundant copies of data (using RAID1, RAID5, RAID6, or RAID10).

Kevin Li
  • 119
  • 3