Here are some thoughts on this: For Softwareraid/Fake-HW-RAID, you can encrypt the single physical volumes, and construct the aray out of those, you could even slice them first, then encrypt them. Now let's assume you first constructed the array, as you'd with a HW Controller. Usually HW Controllers can create a bunch of volumes ontop of a single array, the corrssponding tool would be lvm2 (though lvm2 might be more flexible than what HW controllers offer). Usually you would want to contruct a series of logical volumes in this manner, because it gives you the opportunity, to manage diskspace way better, you can select if chunks are encrypted and in what way. You'd then pull those encrypted volumes together with lvm again in any way you please (I don't see any prticular reason, why stacking lvms should be bad, I'd rather think there are cases, where you certainly want to do this. But if there's already the lvm metadata format, why not use it? Of coursew cryptsetup could print a warning for too big volumes and give a hint, that one would want to create smaller volumes. Another thing to consider,encrypting HW RAID Arrays is completely unrealistic, as long as you do not have massive HW crypto acceleration. Regards -Sven On Tue, April 14, 2009 16:53, Mario 'BitKoenig' Holbe wrote: > 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 > > --------------------------------------------------------------------- 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
