Comments on: Encrypted ZFS Filesystems On Linux

By: EGL

EGL — Thu, 16 May 2013 12:12:46 +0000

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

MN — Sat, 06 Apr 2013 19:42:35 +0000

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

Thu, 14 Feb 2013 13:22:16 +0000

[...] http://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/ [...]

By: Anonymous

Anonymous — Fri, 01 Feb 2013 07:09:56 +0000

“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

Aaron Toponce — Tue, 23 Oct 2012 14:20:49 +0000

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

Jonny — Tue, 23 Oct 2012 13:31:35 +0000

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

Rudd-O — Mon, 22 Oct 2012 18:03:51 +0000

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

Aaron Toponce — Sat, 25 Aug 2012 14:29:37 +0000

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

Brozer — Fri, 24 Aug 2012 20:06:18 +0000

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

Implementing encypted ZFS « 0ddn1x: tricks with *nix — Fri, 24 Aug 2012 17:20:32 +0000

[...] http://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/ Leave a Comment TrackBack URI [...]

By: Loïc

Loïc — Wed, 22 Aug 2012 14:40:09 +0000

Ok then, seems really great

By: Aaron Toponce

Aaron Toponce — Wed, 22 Aug 2012 09:24:47 +0000

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

Loïc — Wed, 22 Aug 2012 08:06:27 +0000

Seems great!

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