Sven Eschenberg wrote: > 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. The issue with separately encrypted physical volumes is that one needs to type in passphrases for each volume, or resorting to storing keys somewhere (I don't like stored keys, they might get stolen along with the encrypted data), or hacking some ugly scripts to reuse passphrases. I currently have software RAID5 > LUKS > LVM and really enjoy the readily available distro integration. It would be really good if this could be addressed within LUKS so separate keys for slices on the large md volume would just be used transparently for the user. On the other hand, I have no idea how feasible it is to mount a statistics attack on eg. my 4x1TB RAID5 setup, vs. bruteforcing a LUKS passphrase of length N. Has someone got a rough estimate? Just to know if we're raising the hurdles where they are low, not just raising the hurdles that are already reasonably high. As a side thought, can the information that it's eg. a RAID5 make a shortcut on revealing the keys, ie. that every Nth chunk is known to be a parity block of the N-1 chunks before? (please bear with me if this is a silly question, I'm no cryptographer) > Of coursew cryptsetup could print a warning for too big volumes and give a > hint, that one would want to create smaller volumes. This would be useful anyways, if there is consensus on which amount of data is "too big" (maybe depending on the chosen method). Yours, Uwe --------------------------------------------------------------------- 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
