On Tue, Apr 14, 2009 at 4:53 PM, Mario 'BitKoenig' Holbe <
Mario.Holbe@xxxxxxxxxxxxx> 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.
>
Yes, we could support this using LUKS. I would rather go for a standard key
splitting schema than for a full set of alternative keys.. This way we don't
run into problems with fixed sized headers when we grow partitions.
A standard key separation technique is
k_1 = E(0^{blocksize}, K)
k_2 = E(0^{blocksize-}1, K)
k_3 = E(0^{blocksize-2}10, K)
k_4 = E(0^{blocksize-3}11, K)
in general
k_n = E(n,K)
where K is the master key.
--
Fruhwirth Clemens http://clemens.endorphin.org
