tcaputi

64 bytes is a bit arbitrary. Up until now I had not heard any complaints about this since most people I know who would use a 64 character passphrase are using a password manager instead. I am adding a test to the PR today and when I do I'll bump it to 512 bytes. We don't want arbitrary password lengths to prevent crazy amounts of passphrase hashing.

We use PBKDF2 as a key derivation function, which is specifically designed to turn low entropy, arbitrary length strings into fixed length, high entropy keys suitable for encryption. It also has the added bonus of making password brute forcing significantly harder.

Yes, there are per filesystem / zvol keys and the raw encrypted data is sent over the wire along with the encrypted keys.

Oracle ZFS does have encryption, but this implementation fixes a few security / usability issues with it, adds more features, and brings the implementation into the open source world.

Thank you for the suggestion. As I said above, there is nothing preventing something like that from being implemented in ZFS in the future. Unfortunately, however, the encryption implementation uses a port of the Illumos Kernel Crypto Framework, which has not yet implemented an SIV mode.

As far as using our own HMAC goes we are using a standard SHA512-HMAC implementation which should be just as secure.

I'm Tom Caputi, author of the ZFS encryption patch and I can answer of few of your questions.

First of all, the choice of AES-CCM. I have had a few people ask me why we didn't chose something like ChaCha20 as a block cipher instead of AES. This is largely because AES is by far the most scrutinized block cipher around. It's use is currently so widely accepted that modern Intel CPUs have built-in AES instructions to improve performance. While its true to say that ChaCha20 (or other block ciphers) might theoretically be faster or that they ARE faster on some architectures like 32-bit cell phone CPUs, this is not currently the case with the vast majority of ZFS deployments.

As far as the choice for CCM as a default goes, this one was a little bit harder. Originally this decision was made to match the Oracle implementation as much as possible (a design decision which has since been dropped). Later, when we re-evaluated the descision, we found a paper (http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comment...) indicating there might be weaknesses with the authentication mechanism, although the paper only mentioned cases with truncated authentication tags. So in the interest of being as conservative as possible, we chose the option which looked the most secure. We did not look into AES-GCM-SIV since it is very new (it looks like it actually came out this year) and so I would not by any means consider it a "conservative" choice.

As far as performance goes, we have not yet (as far as I'm aware anyway) seen a case where read or write speed wasn't bottlenecked by the disk speed. The benchmarks you posted are (as far as I can tell) single threaded and ZFS processes each block asynchronously.

The biggest thing here is that AES-256-CCM is only the default. It is easy for users to pick GCM for the time being and for developers to add newer, better encryption algorithms and change the default as time goes on. I wouldn't be surprised i we had changed the default by the time that the patch ends up in a tagged release.