Comments on: Encrypted ZFS Filesystems On Linux https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/ Linux. GNU. Freedom. Tue, 30 Jan 2018 06:20:48 +0000 hourly 1 https://wordpress.org/?v=5.0-alpha-42199 By: Carlos Lopez https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-266167 Thu, 11 Aug 2016 17:15:23 +0000 http://pthree.org/?p=2469#comment-266167 dm-crypt/LuKS uses block ciphers, so any bit error destroys the whole block. But not more than that.

For example, AES128 uses 128 bits (16 bytes) sized blocks, and AES256 uses 256bits (32 bytes) sized blocks.

Old hard drives will have a sector of at least 512 bytes, which is 16 times bigger than the block cipher size of AES256.

Modern hard drivers now use 4k block sectors (128 times bigger than the block cipher size of AES256)

When a hard drive is damaged and one bad sector is found you don't lose just one bit, but the whole sector.

So, there is really no difference between having dm-crypt on a hard drive or not. You are going to always lose at least one whole block sector worth of bytes, which is many times bigger than the block cipher block size.

And ZFS should have no problem dealing with this. Really...

]]>
By: Mike https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-255678 Tue, 01 Dec 2015 21:31:08 +0000 http://pthree.org/?p=2469#comment-255678 Great article! It is a been a year or so, Aaron. Have you been able to do any testing as in post 19? I would like to keep using ZFS and have LUKS encryption for my 3 disk zpool. Thank you.

]]>
By: Aaron Toponce https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-219385 Tue, 09 Dec 2014 17:50:33 +0000 http://pthree.org/?p=2469#comment-219385 Hmm. You may be right. I may need to think about this further, and possibly do some testing.

]]>
By: Mike DiGrazia https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-211467 Wed, 29 Oct 2014 16:17:15 +0000 http://pthree.org/?p=2469#comment-211467 Aaron, A lot of people here are asking for clarification on how using zfs on top of block level encryption could impact data integrity. I am very interested as well. As I see it, LUKS would present a "plaintext" block level device to zfs and therefore any changes below LUKS would show up above. Granted changing a single bit on the physical storage could affect multiple nearby bits after decryption, this would still result in the violation of zfs checksum and initiate repair. There would probably be a bit more work to repair a single rotten bit but since bit rot is slow and rare I don't see this impacting performance too much, and the repair should still get done -especially in a raidz pool. I am really interested to know if I'm wrong and learn more about how this works.

]]>
By: Aaron Toponce https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-132124 Sat, 12 Apr 2014 21:35:21 +0000 http://pthree.org/?p=2469#comment-132124 It's not that features are bypassed. It's that you can no longer guarantee file integrity. Putting LUKS between the disk and ZFS opens up the possibility that data could get corrupt between LUKS and the disk, and ZFS would not know about it. the ZFS developers spent years closing all the bit rot holes. Putting LUKS underneath ZFS opens one up.

]]>
By: Matt https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-132122 Sat, 12 Apr 2014 06:05:49 +0000 http://pthree.org/?p=2469#comment-132122 Aaron, could you state which features of ZFS are bypassed if you use ZFS on top of a LUKS block device? I can think of none. However, using encryptfs on top of ZFS will prevent effective use of ZFS compression and/or deduplication.

]]>
By: Josh Enders https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-132053 Sun, 23 Feb 2014 11:00:44 +0000 http://pthree.org/?p=2469#comment-132053 Hey Aaron, thanks for the post and series on ZFS. After testing eCryptfs with ZFS, I have unfortunately found a major trade-off that wasn't mentioned. When filename encryption is enabled, as is suggested, there is a limit posed on pre-encrypted filenames to be less than 143 characters in length. [1] Filenames longer than this produce an encrypted name that exceeds the length a ZFS filesystem can store for a filename (255 bytes) and worse yet, results in an unencrypted file.

[1] http://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs

]]>
By: crypt0s https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-131492 Sat, 28 Dec 2013 10:35:39 +0000 http://pthree.org/?p=2469#comment-131492 "...which would bypass a lot of the features ZFS brings to the table..."

for a ZFS mirror:
- cpu load is doubled
- extra attack vector (doubled data)

...what are the other problems to watch for?

]]>
By: Michael https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-129493 Sat, 31 Aug 2013 21:55:20 +0000 http://pthree.org/?p=2469#comment-129493 Im very interested in the drawbacks of using LUKS underneath ZFS as well! Please enlighten us as this is somewhat of a dream setup for many linux users. Thanks in advance!

]]>
By: Hiki https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-126949 Tue, 25 Jun 2013 13:09:06 +0000 http://pthree.org/?p=2469#comment-126949 You can't share an ecrypfs mount over the network though, smb, nfs etc won't work (sftp does work).

]]>
By: EGL https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-126237 Thu, 16 May 2013 12:12:46 +0000 http://pthree.org/?p=2469#comment-126237 Great article! But I'm very curious, as MN, which disadvantages you get when using LUKS below ZFS. As far as I can see, dedup and compression are going to work properly with LUKS as opposed to ecryptfs. What I'm not sure about is are things like 4k sectors and such...

Thank you for clarification!

]]>
By: MN https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-124664 Sat, 06 Apr 2013 19:42:35 +0000 http://pthree.org/?p=2469#comment-124664 Hi Aaron,
Can you help clarify what you mean by "using dmcrypt and LUKS, which would bypass a lot of the features ZFS brings to the table"? As I understand it, using LUKS would just change the underlying raw device to be an encrypted device. Since ZFS would then use that encrypted raw device, we would still be able to take advantage of all it's features. I probably am missing something so any clarification will help!

thanks.

]]>
By: Verschlüsseltes NAS selber aufsetzen (Ubuntu, LUKS, ZFS, RAID) | undkonsortenBlog https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-124236 Thu, 14 Feb 2013 13:22:16 +0000 http://pthree.org/?p=2469#comment-124236 [...] http://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/ [...]

]]>
By: Anonymous https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-123963 Fri, 01 Feb 2013 07:09:56 +0000 http://pthree.org/?p=2469#comment-123963 "Now, granted, encryption algorithms are designed to mimic random data, and it is very hard to compress or deduplicate random data. With that said, it can still be done, and it’s works just fine."

If you can compress your encrypted data, the encryption algorithm is egregiously leaking data. Same goes for deduplication - a crypto implementation that allows one to tell from ciphertext only that the plaintexts are the same is broken

]]>
By: Aaron Toponce https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-117074 Tue, 23 Oct 2012 14:20:49 +0000 http://pthree.org/?p=2469#comment-117074 Not quite. The initialization vector is a nonce, and there is only one. It is what is responsible for kickstarting the CBC process. Further, deduplication sits underneath the encryption layer, not on top. At that level, the blocks are nothing more than zeros and ones. Now, granted, encryption algorithms are designed to mimic random data, and it is very hard to compress or deduplicate random data. With that said, it can still be done, and it's works just fine.

]]>
By: Jonny https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-117072 Tue, 23 Oct 2012 13:31:35 +0000 http://pthree.org/?p=2469#comment-117072 Deduplication will work in that you can turn it on, but you wont find any duplicate data.

Encrypting duplicate files/blocks will result in different data even when using the same key, since the Initialisation Vectors will be different.

In ZFS they got around this by changing the way the IV was calculated when dedup is turned on (see this blog post: https://blogs.oracle.com/darren/entry/compress_encrypt_checksum_deduplicate_with).

So as far as I can tell using 3rd party encryption will make dedup pointless

]]>
By: Rudd-O https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-117069 Mon, 22 Oct 2012 18:03:51 +0000 http://pthree.org/?p=2469#comment-117069 I don't understand what compromises you make with LUKS + ZFS. I have used that and there are no compromises. ZFS works very well with it.

]]>
By: Aaron Toponce https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-116848 Sat, 25 Aug 2012 14:29:37 +0000 http://pthree.org/?p=2469#comment-116848 Deduplication happens at the block level, beneath ZFS. Regardless if the data is encrypted or not, deduplication is still possible. Now, granted, encrypting very similar, yet different data, can result in highly pseudorandom data. This can make data deduplication very difficult, but that doesn't change that with version 32, it's still the same problem, as it uses 256-bit AES. Same is said for compression. So, it's not eCryptFS that is causing these issues, but the disagreement in the technologies. These are the same issues you'll face with the latest version from Oracle. Regardless, the point is that ZFS knows nothing about the data it receives, only what it can do with it after the fact.

]]>
By: Brozer https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-116846 Fri, 24 Aug 2012 20:06:18 +0000 http://pthree.org/?p=2469#comment-116846 Is it really correct to say there are no compromises at all? Granted, any exceptions would be somewhat minimal, and without source access we don't know exactly how Oracle has chosen to implement encryption, BPR etc. But in principle it seems like some ZFS operations would work better if performed on the data as a step before encryption in the chain. It seems likely that dedup, to take Loïc's example, would be more effective if it was done and then the result was randomized rather then after the result was randomized. Compression would be useless (though that of course can get handled farther up) and I don't know if snapshots would be quite as efficient.

It's true that it's mostly transparent though, but in the end I still hope the illumos team comes through with their own native implementation as well as the improvements suggested by Delphix.

]]>
By: Implementing encypted ZFS « 0ddn1x: tricks with *nix https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-116845 Fri, 24 Aug 2012 17:20:32 +0000 http://pthree.org/?p=2469#comment-116845 [...] http://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/ Leave a Comment TrackBack URI [...]

]]>
By: Loïc https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-116838 Wed, 22 Aug 2012 14:40:09 +0000 http://pthree.org/?p=2469#comment-116838 Ok then, seems really great 🙂

]]>
By: Aaron Toponce https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-116837 Wed, 22 Aug 2012 09:24:47 +0000 http://pthree.org/?p=2469#comment-116837 Yes they will. Of course they will. The eCryptfs filesystem resides "on top" of ZFS. So, as far as ZFS is concerned, it's just standard, run-of-the-mill data. It doesn't know any different. So, all of the benefits ZFS brings are still there. No compromises are made. Unlike ZFS on top of LUKS.

]]>
By: Loïc https://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/#comment-116835 Wed, 22 Aug 2012 08:06:27 +0000 http://pthree.org/?p=2469#comment-116835 Seems great! 🙂

But I don’t think dedup and/or compression will continue to work as they did before, no?

]]>