Plans to avoid weaknesses in big volumes? (was: Re: SMP-aware kcryptd?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sven Eschenberg <sven@xxxxxxxxxxxxxxxxxxxxx> wrote:
> Volumes >> 1TB have certain weaknesses - this is pretty much true for 
> all block chaining enrcyption schemas.
> Even though if you use a hardware raid 5(6) controller, you should have 
> a collection of several logical volumes on top of it, each encrypted 
> with a different key.

Hmmm, if it's known that larger volumes yield to weaker security
guarantees... are there any plans to circumvent this fact using LUKS?

I mean, plain device-mapper just supports the construction of volumes
from multiple sources, so without LUKS it should be easily possible to
construct a big encrypted volume from dm-crypted chunks of a large
physical volume each of which is encrypted with a different key using a
dm-table like:
 0 1073741824 crypt aes-xts-plain 1stkey 0 /dev/disk0 0
 1073741824 1073741824 crypt aes-xts-plain 2ndkey 0 /dev/disk0 1073741824
 2147483648 1073741824 crypt aes-xts-plain 3rdkey 0 /dev/disk0 2147483648
 ...
for 0.5T chunks.

However, it would be nice, if LUKS could support this "native".
IMHO all the things to change should be located in the cryptsetup tool
and in the LUKS header format. A chunk size would need to be stored
somewhere and the key-slots need to contain a list of master keys
instead of a single one. The key-slot size would need to be increased,
but given the current size of a LUKS header, there should be plenty of
room for additional master keys.
I'm not sure if the diffusion-size of the key material could be kept
constant for the larger key, but I guess it could.
I don't know if it would be clever (and safe :)) to somehow derive a
list of master keys from a single source-key - I'm pretty sure methods
to do so would heavily depend on the encryption algorithms finally used.


regards
   Mario
-- 
$ make fire
Don't know how to make fire
$ Why not?
No match


---------------------------------------------------------------------
dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
For additional commands, e-mail: dm-crypt-help@xxxxxxxx


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux