Do I really need encryption?

[panz]

tl;dr: Current FreeNAS GELI encryption is a Bad Idea IMO. Do it a different way.:p

So, current encryption in FreeNAS is not implemented the right way. Would you mind elaborating the concept? I'm very interested.

 

[DaPlumber]

So, current encryption in FreeNAS is not implemented the right way. Would you mind elaborating the concept? I'm very interested.

5th paragraph for better current work- arounds. ;):p

"Plug in" code modules like compression would be ideal. As an interesting experiment I wonder if anyone's tried creating a pseudo compression module for ZFS that actually does encryption?

 

[panz]

I can't understand why GELI is dangerous to ZFS the same way as a RAID card.

 

[DaPlumber]

I can't understand why GELI is dangerous to ZFS the same way as a RAID card.

Because both are virtualizing (lying about) disk device access. ZFS is a "clean sheet" architecture that assumes dumb JBODs. Do you really want an error in encryption or decryption being interpreted as a disk error? Think about potential deadlocks and timeouts in parallel processing of the two code paths, and so on.

BTW this is a FreeBSD (and others) issue with how ZFS is implemented in the OS, not a FreeNAS issue per se.

 

[panz]

So, a solution like PEFS or encFS-like would be better?

 

[titan_rw]

I have played with client side encryption on a non encrypted zpool.

For example, non-encrypted zpool exporting an iscsi lun. Windows mounts that iscsi lun. Truecrypt on windows encrypts it and formats with ntfs, assigning a drive letter on the windows box.

Compression on freenas will be useless as the freenas contents are all 100% random data. But you get a zfs backed (bit rot protected) encrypted ntfs drive 'local' (as in shows up in disk manager, not an SMB share) to your windows machine. Feel free to snapshot / replicate it as well. (note you're not properly quesing the filesystem before snapshots, so each snapshot will be of a 'dirty' ntfs drive.) Also note that simply 'adding' data to the ntfs drive will result in 'changed' data on the zpool. So snapshots will have higher overhead as they have to track the old 'freespace encrypted to random data' changing to 'non freespace encrypted to different random data'. So snapshots could also be a security concern since someone could easily tell which portions of the random data are changing, and when. Might make plausible deny ability harder.

This also offloads the encryption to the windows box too. So you don't need to worry about the freenas cpu supporting aes-ni. And even without aes-ni on the desktop, truecrypts software encryption being multithreaded, most cpu's should manage gigabit with too much issue.

 

[DaPlumber]

So, a solution like PEFS or encFS-like would be better?

If done on the client end to an (e.g.) iSCSI exported lvol, yes that's what I was talking about, but not on the FreeNAS server end. Better (IMO) from a security and architectural perspective, but not neccessarily from that of performance or ease-of-administration.

 

[DaPlumber]

What titan_rw said. :D

The Mac equivalent would be a core services Filevault2 volume on iSCSI (PITA), or easier: an encrypted Sparse dmg on a share. (The latter is good for things like DropBox too.)