I think we've settled on AES-256, but may entertain AES-128
if there is a huge performance difference as I think AES-128
is still considered sufficiently safe for our purposes.
The performance difference should be relatively small.
That's my thought too, especially with AES-NI.
So, the question is mainly what mode of operation would be
best?
- cbc-essiv
- ctr-{plain64|essiv}
- xts-{plain64|essiv}
- are there any others I should be considering?
NOTE: I'm not sure if essiv is even an option for CTR or XTS
modes, I'd like feedback on that, as well as what the
security implications are...
ESSIV is only for CBC.
Ah, ok, that's good to know. Thanks.
At this point, I'm leaning towards CTR mode, mainly because it
was designed explicitly to be parallelizable:
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29
That is only for fine-grained paralellism, and hence not
applicable here. I am also not sure whether you can even use it
with dm-crypt as it needs a nonce in addition to the counter.
And that needs to be stored somewhere.
Well, since Intel provided a specific CTR mode AES-NI patch and
it referenced testing it _using_ dm-crypt
(http://lwn.net/Articles/376562/), I'd assume it is possible to at
least use it with dm-crypt ;)
Unless you have any specific security requirements beyond
the standard, go with the defaults. I think you are
overthinking this. The defaults are what is maintained best
and also what will get the fastest fixes and problem detection.
No specific security requirements. I'm not worried about
governments targeting breaking this encryption or anything
like that. Just want to make sure the actual storage of this
data isn't the weakest link in the security chain.
If you have special requiremenrts, any deviation from the
defaults should have a strong justification comming from
these requirements. As you have not given any, I cannot
comment on them.
Sorry, I should have provided more information...
The requirements are basically if the box leaves the building,
that it be infeasible that the plaintext data be retrieved.
Not worried about leakage of statistics or even modification
of data, though if those too can be prevented for little cost,
it'd be nice to have ;)
As for speed, AFAIK, basically you are still limited to
one CPU per process that accesses an encrypted disk.
But keep in mind that with the defaults you get something
like 100MB/s crypto speed in pure software. Unless this thing
has an 2.5 or 10Gb/sec interface, and SSDs or mostly
linear, large-file accesses, that is quite fast enough
in most cases.
This is a multi-user fileserver hosting remote home directories
(just across the LAN) for Linux and Mac users, primarily developers,
who could be doing anything from compiling code, to tar'ing files,
to heck, even running a VM from the network filesystem (though
that last one won't exactly be recommended).
It _will_ be a pure SSD RAID subsystem (LSI 9260-8i RAID 5 using
8 Intel 320series SSD drives), and interconnected to our network backbone
with a 10Gb/sec interface (SFP+ twinaxial direct-connect). Though
each developer's workstation will be limited to gigabit speeds, the
aggregate of multiple workstations could be higher, and we don't
want the remote share to be a bottleneck.
A combination of NFSv3 and NFSv4 will be used, I'd need to research
this point, but I'd assume each workstation's connection would be
handled via its own process or thread within NFS, so it should be
able to scale multi-core.
Thanks.
-Brad
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
