Geli data authentication / verification

[Intropy]

Has anyone here tried using geli verification (-a aalgo) with FreeNAS? I'm thinking about using it and would like to see what other experiences have been. Does it slow access down too much? Does it verify on write or only after a subsequent read?

 

[Dusan]

Why would you want to do that? ZFS already includes end-to-end checksum based integrity checking: https://en.wikipedia.org/wiki/ZFS#ZFS_data_integrity

 

[Intropy]

Summary: I really just want a way to do a round-trip check on all encryption at writing time to make sure nothing gets corrupted in the process.

It would protect against corruption while encrypting. My data is by far dominated by video with lossy encoding. missing a few bytes here or there doesn't actually do much harm. If I hand geli some corrupt bytes it'll happily encrypt it, the zfs checksums will match, decrypting will work and give me the same slightly corrupted data as geli was given. Not a big deal.

If there's a corruption while taking the ZFS checksum then ZFS should notice that and error handling will commence. This is okay.

If I hand geli some data and it encrypts it and there's a corruption during encryption then the corrupt encrypted data will get handed to ZFS which will checksum it and it'll pass. Then on reading it it will fail to decrypt, effectively taking out a whole block of data with it. This is the bad case. On the other hand if there a geli verification checksum and geli does an immediate check of the data (which I'm not sure it does) then the error will be detected during the write process instead of only when later attempting to decrypt it. Detecting an error here I'd hope geli does something smart like attempting another encryption or reporting a disk failure up the stack.

I guess, come to think of it, the verification checksum isn't really necessary. All I really need is geli to attempt a decryption on writing. A less convenient alternative is to ensure that every application that writes to the disk does it's end to end verification. That may not be achievable realistically.

A second reason one may want geli verification but which doesn't concern me is to ensure that all data on the drive was really written by you. Without the checksum it is possible that the drive could have been tampered with and you would not know it.

 

[cyberjock]

You really are confusing yourself trying to prevent corruption. Your solution is to use ZFS(which is the only option with geli) and ECC RAM. Then there is no way that the handoff from ZFS to geli to the disks will result in corruption, so long as you have enough parity data to recover from the corruption and don't have a software glitch. And a software glitch is extremely unlikely considering how tested the software is.

So just make sure you use ECC RAM, which you should be using with ZFS anyway, and forget all this stuff.

And no, you don't really "need geli to attempt a decryption on write". geli will happily decrypt trash data, but ZFS will also happily fix the corruption.

 

[Dusan]

If I hand geli some data and it encrypts it and there's a corruption during encryption then the corrupt encrypted data will get handed to ZFS which will checksum it and it'll pass.

This is not how it works. Geli is a layer below ZFS. ZFS never handles the encrypted data. If anything fails in the ecryption/decryption process, ZFS will catch it and, as compared to Geli verification, will be able to "heal" the data if you have redundancy. There is also a big benefit of not storing the checksum inside the sector with the checksummed data and being able to verify that the checksum itself is correct (and not merely matching the data) -- a tree of checksums. It's all explained here: https://blogs.oracle.com/bonwick/entry/zfs_end_to_end_data
Example: if you copy (dd) an entire sector between locations on the disk (or copy a previously seen sector you backed up), Geli will never detect such change -- the sector matches the checksum so Geli is happy. However, the tree of checksums in ZFS will detect such change.

 

[Intropy]

Below? Now that is interesting. In that case the only use case I can see is to detect tampering, and I'm not concerned about that. Thank you for the information, Dusan.

 

[Dusan]

Even the protection against tampering is limited. It will not protect against replay attacks. You can copy/replace entire sectors any Geli won't notice.