LWN: Comments on "Adding encryption to Btrfs"

Adding encryption to Btrfs

magila — Thu, 29 Sep 2016 04:31:21 +0000

I'm not aware of any published comparisons. I've done some informal testing on my own machine, a quad core Skylake running at 4.5GHz, with 8K blocks and found:

ChaCha20 achieves 16.4GB/s while consuming 102W or 5.93 microjoules/byte
AES-128-CTR achieves 22.4 GB/s while consuming 87W or 3.70 microjoules/byte
AES-256-CTR achieves 16.6 GB/s while consuming 82W or 4.71 microjoules/byte

You might argue comparing AES-128 to ChaCha20 is unfair, but the fact is those are by far the most widely used variants of each.

ChaCha20 was tested using the benchmark tool from https://github.com/floodyberry/chacha-opt modified to run ChaCha20-avx2 with 8K blocks in a loop
AES was tested using the example code from https://wiki.openssl.org/index.php/EVP_Symmetric_Encrypti... modified to encrypt 8K blocks in a loop.
All tests were done with 4 instances running in parallel.
Power consumption was measured using CPUID HWMonitor.

Adding encryption to Btrfs

jtaylor — Tue, 27 Sep 2016 14:36:43 +0000

I'm curious, do you have a source for that claim?

Adding encryption to Btrfs

cwillu — Mon, 26 Sep 2016 07:35:23 +0000

I'd hesitate to consider the lack of progress on the encryption front to be evidence of stagnation; I certainly spent some time harping at cmason and company that encryption was not something that should be attempted without encryption experts getting involved. My harps were mostly of the "obvious approach A will cause non-obvious failure modes 1, 2, 3", and I don't feel they needed much convincing at the time (or maybe cmason and josef will say anything to shut me up :p).

Adding encryption to Btrfs

magila — Fri, 23 Sep 2016 16:15:29 +0000

Even on larger CPUs hardware AES is more power efficient. The SIMD units are by far the most power hungry logic units in modern Intel CPUs.

Adding encryption to Btrfs

epa — Fri, 23 Sep 2016 13:41:49 +0000

I thought that hardware AES was really for the benefit of weaker, embedded processors which can't do software encryption as fast.

Adding encryption to Btrfs

masoncl — Thu, 22 Sep 2016 17:58:50 +0000

I think we're definitely not doing a great job of talking about our progress, but overall development of Btrfs hasn't slowed down at all. Stability is dramatically better and it's used in production here at FB.

Adding encryption to Btrfs

flussence — Thu, 22 Sep 2016 17:01:25 +0000

With Btrfs being funded by the likes of Facebook I imagine there's less of a pressing need to make RAID-5/6 work. They can afford to do RAID-over-HTTP...

Adding encryption to Btrfs

rahvin — Thu, 22 Sep 2016 15:38:01 +0000

Does anyone know why btrfs development essentially stagnated? Is it because Oracle as the primary developer early on redirected resources after buying Sun and gaining access to zfs? I ask this because for a few years it looked like btrfs was making fantastic process but haven't seen major announcements or visible improvements for a while.

Adding encryption to Btrfs

koverstreet — Thu, 22 Sep 2016 15:27:25 +0000

highly relevant (and excellent) article explaining XTS:

https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

Adding encryption to Btrfs

dkg — Thu, 22 Sep 2016 15:10:12 +0000

exactly. AES is a block cipher, and XTS is a cipher mode. XTS is one way to use AES, and doesn't rule out hardware-accellerated AES at all, afaik. Wikipedia has a good page of description about cipher modes.

Authenticated encryption modes would also be great, as they're tamper-evident -- any modification or damage to the ciphertext results in unreadable data (aka "⊥"), rather than returning nonsense cleartext.

Adding encryption to Btrfs

koverstreet — Thu, 22 Sep 2016 14:56:00 +0000

Yeah, mistyped that.

Adding encryption to Btrfs

ballombe — Thu, 22 Sep 2016 14:08:15 +0000

> that will tend to rule out "exotic encryption modes" in favor of something boring (but hardware-supported) like AES.

AES is not an "encryption mode"...

Adding encryption to Btrfs

micka — Thu, 22 Sep 2016 08:16:34 +0000

I suppose you meant "faster than AES in hardware". At least, from your link:

> on Haswell, ChaCha20 (in software) is over 2x as fast as AES (in hardware), at realistic (for a filesystem) block sizes

Adding encryption to Btrfs

koverstreet — Thu, 22 Sep 2016 05:18:40 +0000

No mention of bcachefs encryption? https://bcache.evilpiepirate.org/Encryption/

A COW filesystem is an opportunity to do encryption significantly better than existing disk level or filesystem level encryption - update in place is the main obstacle to things like randomized encryption and nonces. Once you're doing data checksumming by storing the checksums with the pointers, not the data, you've got most of what you need for AEAD style encryption - which really is the modern gold standard. That's what bcachefs is doing, and I don't see why btrfs couldn't do something similar.

Also, as I commented on the btrfs mailing list, encryption in hardware is not necessarily faster - ChaCha20 in software is generally faster than AES in software: http://www.spinics.net/lists/linux-btrfs/msg59034.html