[dm-crypt] Wrong behavior?

Sven Eschenberg sven at whgl.uni-frankfurt.de
Wed Jul 14 00:17:31 CEST 2010

Hi Milan,

On Tue, 2010-07-13 at 23:12 +0200, Milan Broz wrote:
> On 07/13/2010 10:51 PM, Sven Eschenberg wrote:
> > Hi list, I just tried to issue the following command:
> > 
> > cryptsetup -c aes-xts-plain -s 256 -i 5000
> > --master-key-file /kspace/tmpmaster
> > luksFormat /dev/md125 /kspace/tmpkey.0
> > 
> > where tmpmaster and tmpkey.0 are binary files with entropy I wish to use
> > for (tmpmaster) master key for the volume and (tmpkey.0) passphrase/key
> > in key slot 0.
> > 
> > When I run the command, cryptsetup asks for a passphrase nevertheless,
> > although it is stated:
> > 
> > luksFormat <device> [<new key file>] - formats a LUKS device
> > 
> > As an alternative, I tried passing the key file for the slot via
> > --key-file since the manpage states this has precedence if used. No
> > change though.
> > 
> > Is this a know bug?
> you mean that keyfile should be used there?
> Yes, I think it is not supported yet, easy to fix it though, can you please
> add this to issues on google page?
> (I'll fix it but later.)

Just added an issue, hope the description is sufficient.

> (that option was meant for key escrow recovery mainly, for format you want
> to use RNG generated master key in most situations)

Well, yet it gives me the chance to use the RNG of my choice, might it
be a HW-RNG in a TPM or chipset, in software of my choice or
whatsoever ;-). Well, maybe I would want to play with own RNGs and no, I
am not gonna use any PRNG using linear congruences for that matter :-).

> Milan
> > P.S.: Do I remember correctly, that the payload offset given by luksDump
> > is always in 512 bytes sectors?
> yes.

Humm, I was just thinking, obviously cryptsetup uses the readahead of
the device as a measure for alignment.
On a 512kb chunked raid 6 with 4 disks the alignment is chosen as 4096
sectors, although aligning to 2048 sectors would be more accurate.
512kb chunks on a 3 disk raid 5 will yield 6144 sectors readahead, Well
for that matter obviously 1.5 MB stripes as readahead do not work, 3 MB
as readahead (2 complete stripes) is somewhat okay, but alignment should
actually be on 1 MB boundary (though 3 MB will be a rather minor loss).

I wonder how this would turn out in something like 512kb chunks, on a 9
disk raid 6, yielding in 4.5 MB stripe size (with 3.5 MB real data per
stripe), probably a 9 MB readahead?
Now we have a problem, because 9 MB is not aligned anymore, well at
least not to the data, we would need to have a multiple of 3.5 MB.

Or would we really end up with a 63 MB readahead and would align the
dmcrypt payload to that boundary? That seems a little nuts ;-).



> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

More information about the dm-crypt mailing list