Project

General

Profile

Feature #23645

Change encryption to at least allow, if not simply use AES-256.

Added by Cyber Jock over 3 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Critical
Assignee:
Bartosz Prokop
Category:
Middleware
Target version:
Estimated time:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:

Description

TrueNAS customer with a contract with us is using an encrypted zpool. They do contracts for medical records storage, and some vendors are requiring AES-256. Our customer has asked if we can add support for AES-256. He recognizes that AES-256 is a bit "over the top" but this is impacting his own potential customers, and if we cannot add this he may have to look at alternatives such as Linux. He said that now that Linux on ZFS is mature and Canonical is beginning to offer servers with ZFS on them and he can use encryption and choose AES-256, he feels this is necessary for his continued use of TrueNAS.

Thanks.

Associated revisions

Revision 7a326677 (diff)
Added by 650elx over 3 years ago

Change encryption key length to AES-256 for zpools. Ticket: #23645

Revision fbf2276a (diff)
Added by 650elx over 3 years ago

Change encryption key length to AES-256 for zpools. Ticket: #23645 (cherry picked from commit 7a3266777cf6f58650f0039cdfaa36b260c6ca4e)

Revision d674614e (diff)
Added by Warren Block over 3 years ago

Encrypted volumes now use AES256. Ticket: #23645

History

#1 Avatar?id=14398&size=24x24 Updated by Kris Moore over 3 years ago

  • Assignee set to William Grzybowski

William, are we already on AES-XTS 256?

#2 Updated by William Grzybowski over 3 years ago

  • Status changed from Unscreened to Screened
  • Target version set to 11.0

It is AES-XTS but 128.

#3 Updated by William Grzybowski over 3 years ago

  • Priority changed from No priority to Important

#4 Updated by William Grzybowski over 3 years ago

Question is, should we just use 256 by default or provide a choice? 128 or 256?

#5 Avatar?id=14398&size=24x24 Updated by Kris Moore over 3 years ago

Dunno, is it significantly slower to use 256 vs 128? If not I'd say we just default it to 256 and call it a day ;)

#6 Updated by Cyber Jock over 3 years ago

A couple of years ago I tested AES-NI with AES-128 and AES-256. Yes, it is slower. But when using both AES-128 and AES-256 and the bottleneck was the ramdisk I was using, it was hard to say "yep, it really is slower". If memory serves me right the throughputs I saw were either 1GB/sec or 2GB/sec.

So I'm not against making AES-256 the default, but the conservative side of me makes me cautious about if we really want to make the default AES-256 without a little more testing. And I'm not sure how we'd handle already-encrypted zpools in FreeNAS/TrueNAS if we make the change.

#7 Updated by William Grzybowski over 3 years ago

  • Status changed from Screened to Unscreened
  • Assignee changed from William Grzybowski to Anonymous

Bartosz, is this something you think is currently within your reach?

We need to know how big the performance impact of AES-256 vs AES-128 is. If they are big enough we will need another encryption attribute (key length) to choose from, and see how they interact with each other.

#8 Updated by Anonymous over 3 years ago

  • Status changed from Unscreened to Screened

I'm going to perform some testing and paste the results here.

#9 Updated by William Grzybowski over 3 years ago

  • Project changed from TrueNAS to FreeNAS
  • Category changed from 14 to 201
  • Priority changed from Important to Critical
  • Target version changed from 11.0 to 11.0
  • Private changed from No to Yes

#10 Updated by Anonymous over 3 years ago

I've tested both key options and in my simple testing and VM setup it's around 10% - 15% faster for the 128bit key option(tested only with AES-NI). I'm going to stress my Mini on some bigger files tomorrow morning and compare the results.

Looking through FreeBSD forums my results seems to be fine.
Linux for example (Intel official test) is faster around 30% for the 128bit option.

I think that giving users key length option is not a bad thing. Manual pool setup form is not especially crowded and advanced users may appreciate that.

#11 Updated by Anonymous over 3 years ago

After testing on my Mini I still see around 10% difference. I've tested scenarios with UFS and ZFS, HDD and SSD, small random files in high amount and big random files.

We can go further and test high IOPS scenario like database etc.

IMO key length with AES-NI may have impact on applications like OpenVPN, but when storage is involved the difference is not that significant.

As I wrote in previous comment making an option for key length is not a bad thing.

#12 Updated by William Grzybowski over 3 years ago

Bartosz Prokop wrote:

After testing on my Mini I still see around 10% difference. I've tested scenarios with UFS and ZFS, HDD and SSD, small random files in high amount and big random files.

We can go further and test high IOPS scenario like database etc.

IMO key length with AES-NI may have impact on applications like OpenVPN, but when storage is involved the difference is not that significant.

As I wrote in previous comment making an option for key length is not a bad thing.

I am not sure it is worth the trouble if the difference is that small. My opinion is that we should just do 256 (if people complain we can add a choice [128, 256]).
Thoughts, Kris?

Can you go ahead and test interchangeability between 128 and 256? (e.g. created a volume with 128 and then start replacing disks with 256 to make sure everything still works OK?)

#13 Updated by Anonymous over 3 years ago

Ok, I can test a pool out with the 128bit GELI partitions and then swap some of them for the 256 bit one.

#14 Avatar?id=14398&size=24x24 Updated by Kris Moore over 3 years ago

Yea, if we can change to 256 without breaking previously created 128 pools, I'd say just up it to 256-bit and call it good. If we see too many folks noticing a performance regression we can re-eval adding a selector in 11.1.

#15 Updated by Anonymous over 3 years ago

Sorry for a delay - I've had a support related thing.

I've created a pool on FreeBSD 11 with two 128bit key mirrored drives and then replaced one with a 256 key one.
It looks like the GELI abstraction layer is working just fine. I haven't found any problems.

#16 Updated by William Grzybowski over 3 years ago

Bartosz Prokop wrote:

Sorry for a delay - I've had a support related thing.

I've created a pool on FreeBSD 11 with two 128bit key mirrored drives and then replaced one with a 256 key one.
It looks like the GELI abstraction layer is working just fine. I haven't found any problems.

Great, then please just switch us to use 256 and we can call it done.

Thanks!

#17 Updated by Anonymous over 3 years ago

I've prepared and tested a fix for the 256 bit encrypted zpool and it looks fine - I can push it tomorrow.
Last question; do we care about swap being encrypted with 256 key ? The default value is 128bit and customer asked only about encrypted zpool.

#18 Updated by William Grzybowski over 3 years ago

Bartosz Prokop wrote:

I've prepared and tested a fix for the 256 bit encrypted zpool and it looks fine - I can push it tomorrow.
Last question; do we care about swap being encrypted with 256 key ? The default value is 128bit and customer asked only about encrypted zpool.

I'd think leaving swap out of it is fine.

#19 Updated by Anonymous over 3 years ago

  • Status changed from Screened to Needs Developer Review

#20 Updated by William Grzybowski over 3 years ago

  • Status changed from Needs Developer Review to Reviewed

For the future please assign to someone for the review (Or to VB if you dont know who).

Thanks!

#21 Updated by Vaibhav Chauhan over 3 years ago

  • Status changed from Reviewed to Merged

#22 Updated by Vaibhav Chauhan over 3 years ago

  • Target version changed from 11.0 to 11.0-RC3

#23 Updated by William Grzybowski over 3 years ago

  • Assignee set to Bartosz Prokop

#24 Updated by Vaibhav Chauhan over 3 years ago

  • Status changed from Merged to Resolved

#25 Updated by Dru Lavigne over 3 years ago

  • Private changed from Yes to No

Also available in: Atom PDF