[dm-crypt] Wrong behavior?

[dm-crypt] Wrong behavior?

[Sven Eschenberg]

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?

cryptsetup is still v1.1.2

Regards

-Sven

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

Re: [dm-crypt] Wrong behavior?

[Milan Broz]

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.)

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

Milan


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

yes.

Re: [dm-crypt] Wrong behavior?

[Sven Eschenberg]

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 ;-).


Regards

-Sven

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

Re: [dm-crypt] Wrong behavior?

[MkFly]

On Tue, Jul 13, 2010 at 3:17 PM, Sven Eschenberg
<sven@whgl.uni-frankfurt.de> wrote:
> 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 :-).

Well now I'm wondering, does luksFormat use /dev/urandom for
master-key generation?  If so, is there any way to force it to use
/dev/random instead (aside from generating a keyfile beforehand and
luksFormat'ing with --master-key-file)?

Re: [dm-crypt] Wrong behavior?

[Heinz Diehl]

On 14.07.2010, MkFly wrote: 

> Well now I'm wondering, does luksFormat use /dev/urandom for
> master-key generation?

Yes, it does.

>  If so, is there any way to force it to use
> /dev/random instead (aside from generating a keyfile beforehand and
> luksFormat'ing with --master-key-file)?

If I remember correctly, this has been discussed here before, and one of
the main reasons against using /dev/random was that it's blocking when
it's out of entropy.

Re: [dm-crypt] Wrong behavior?

[Milan Broz]

On 07/14/2010 08:38 AM, Heinz Diehl wrote:
> On 14.07.2010, MkFly wrote: 
> 
>> Well now I'm wondering, does luksFormat use /dev/urandom for
>> master-key generation?
> 
> Yes, it does.

I want add rng selection to 1.3.x, no eta yet, there is issue for that
on project page. And several discussions already:-)

I was quite disapponted how gcrypt RNG works so code will stick
with using /dev/random for long-term key, urandom for other things (wipe, salt).

There will be option to use RNG for key generation - for now it should
support random/urandom/gcrypt(very strong) RNG (with /dev/random as default).

Milan

Re: [dm-crypt] Wrong behavior?

[Arno Wagner]

On Wed, Jul 14, 2010 at 08:38:56AM +0200, Heinz Diehl wrote:
> On 14.07.2010, MkFly wrote: 
> 
> > Well now I'm wondering, does luksFormat use /dev/urandom for
> > master-key generation?
> 
> Yes, it does.
> 
> > ?If so, is there any way to force it to use
> > /dev/random instead (aside from generating a keyfile beforehand and
> > luksFormat'ing with --master-key-file)?
> 
> If I remember correctly, this has been discussed here before, and one of
> the main reasons against using /dev/random was that it's blocking when
> it's out of entropy.

Specifically, the issue was what to do in a low-entropy environment
(embedded system) on automatic install. On an ordinary PC on second
boot or so, /dev/urandom typically produces very good key material.

Arno

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] Wrong behavior?

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

On Wed, 2010-07-14 at 12:09 +0200, Arno Wagner wrote:
> Specifically, the issue was what to do in a low-entropy environment
> (embedded system) on automatic install.
I just can point out my previous argument once again:

As the entropy is only required once (when setting up LUKS) there should
be no issue with embedded devices per se.

It's rather a problems for all kinds of automatically installed systems
and there I'd say:
- These systems usually don't use encryption anyway.
- Even I they does they'll typically require manual intervention anyway
(entering a password, providing a key file, etc.)
- And apart from that: cryptsetups main target should always be maximum
security. Therefore it would be IMO better to life (for now) with
blocking systems than using urandom.


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Wrong behavior?

[Milan Broz]

On 07/14/2010 12:17 AM, Sven Eschenberg wrote:
> 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 :-).

You can add second keyslot using keyfile and remove former afterwards as workaround.
But if you want to do such low level operations, maybe you want to use dm-crypt
directly, without luks...

> Humm, I was just thinking, obviously cryptsetup uses the readahead of
> the device as a measure for alignment.

No, readahead has nothing to do with device alignment. We are using device topology
as defined by stacking device, this approach is now supported by all
tools (fdisk & partitioning toos, lvm2, mdadm, cryptsetup).

If topology IOCTLs are not supported (kernels <2.6.32 iirc) it simply defaults
to alignment of 4k.

MD of course provides proper value according to configured mode (chunks etc).

Readahead is set the same as underlying device, readahead is dynamic property
of device (you can change it using blockdev --setra anytime) while alignment
is calculated during device format and cannot be changed later.)

Milan

Re: [dm-crypt] Wrong behavior?

[Sven Eschenberg]

Hi Milan,

On Wed, 2010-07-14 at 09:58 +0200, Milan Broz wrote:
> On 07/14/2010 12:17 AM, Sven Eschenberg wrote:
> > 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 :-).
> 
> You can add second keyslot using keyfile and remove former afterwards as workaround.
> But if you want to do such low level operations, maybe you want to use dm-crypt
> directly, without luks...

Yes, since I usually use 2 key slots and 2 keys stored at different
locations (since one keystore might get corrupted) I can setup up with
some initial passphrase, set the second key to slot 1 and afterwards the
primary to slot 0. No worries there - Just saying, it should be fixed
whenever possible.

> 
> > Humm, I was just thinking, obviously cryptsetup uses the readahead of
> > the device as a measure for alignment.
> 
> No, readahead has nothing to do with device alignment. We are using device topology
> as defined by stacking device, this approach is now supported by all
> tools (fdisk & partitioning toos, lvm2, mdadm, cryptsetup).
> 
> If topology IOCTLs are not supported (kernels <2.6.32 iirc) it simply defaults
> to alignment of 4k.
> 
> MD of course provides proper value according to configured mode (chunks etc).
> 
> Readahead is set the same as underlying device, readahead is dynamic property
> of device (you can change it using blockdev --setra anytime) while alignment
> is calculated during device format and cannot be changed later.)
> 
> Milan

Is there any 'easy' way to access this information. specifically I am
interested, why md would report a 6144 sectors alignment on my 4 disk
raid5 with 512 kb chunks instead of 3072.

Regards

-Sven

Re: [dm-crypt] Wrong behavior?

[Milan Broz]

On 07/14/2010 01:39 PM, Sven Eschenberg wrote:

> Is there any 'easy' way to access this information. specifically I am
> interested, why md would report a 6144 sectors alignment on my 4 disk
> raid5 with 512 kb chunks instead of 3072.

Values are in in sysfs also, I am just using topology ioctl which is simpler.

sysfs interface
---------------
/sys/block/<disk>/alignment_offset
/sys/block/<disk>/<partition>/alignment_offset
/sys/block/<disk>/queue/physical_block_size
/sys/block/<disk>/queue/logical_block_size
/sys/block/<disk>/queue/minimum_io_size
/sys/block/<disk>/queue/optimal_io_size

cryptsetup uses minimal/optimal io_size and alignment value
to calculate payload offset.

A lot of info here:

http://people.redhat.com/msnitzer/docs/io-limits.txt
https://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues

Milan

Re: [dm-crypt] Wrong behavior?

[Sven Eschenberg]

Hi Milan,

thanks for the info and links. What I do not understand is this, I will
use the easiest version for now:

cryptsetup luksFormat /dev/md125

And:

LUKS header information for /dev/md125

Version:       	1
Cipher name:   	aes
Cipher mode:   	cbc-essiv:sha256
Hash spec:     	sha1
Payload offset:	4096

But:

cat /sys/block/md125/queue/minimum_io_size 
524288

cat /sys/block/md125/queue/optimal_io_size 
1048576

whilst physical and logical blocksize are at 512 bytes.

I don't see why cryptsetup does not end up with 1024 sectors (which is
the optimal_io_size) - or is the luks header bigger than 512k? even
bigger than 1 MB (2048 sectors) ?

Regards

-Sven




On Wed, 2010-07-14 at 13:52 +0200, Milan Broz wrote:
> On 07/14/2010 01:39 PM, Sven Eschenberg wrote:
> 
> > Is there any 'easy' way to access this information. specifically I am
> > interested, why md would report a 6144 sectors alignment on my 4 disk
> > raid5 with 512 kb chunks instead of 3072.
> 
> Values are in in sysfs also, I am just using topology ioctl which is simpler.
> 
> sysfs interface
> ---------------
> /sys/block/<disk>/alignment_offset
> /sys/block/<disk>/<partition>/alignment_offset
> /sys/block/<disk>/queue/physical_block_size
> /sys/block/<disk>/queue/logical_block_size
> /sys/block/<disk>/queue/minimum_io_size
> /sys/block/<disk>/queue/optimal_io_size
> 
> cryptsetup uses minimal/optimal io_size and alignment value
> to calculate payload offset.
> 
> A lot of info here:
> 
> http://people.redhat.com/msnitzer/docs/io-limits.txt
> https://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues
> 
> Milan

Re: [dm-crypt] Wrong behavior?

[Arno Wagner]

The LUKS header is 1'052'672 bytes with default parameters.
See FAQ Item "What does the on-disk structure of LUKS look like?"
in section 5.

Arno


On Wed, Jul 14, 2010 at 02:07:19PM +0200, Sven Eschenberg wrote:
> Hi Milan,
> 
> thanks for the info and links. What I do not understand is this, I will
> use the easiest version for now:
> 
> cryptsetup luksFormat /dev/md125
> 
> And:
> 
> LUKS header information for /dev/md125
> 
> Version:       	1
> Cipher name:   	aes
> Cipher mode:   	cbc-essiv:sha256
> Hash spec:     	sha1
> Payload offset:	4096
> 
> But:
> 
> cat /sys/block/md125/queue/minimum_io_size 
> 524288
> 
> cat /sys/block/md125/queue/optimal_io_size 
> 1048576
> 
> whilst physical and logical blocksize are at 512 bytes.
> 
> I don't see why cryptsetup does not end up with 1024 sectors (which is
> the optimal_io_size) - or is the luks header bigger than 512k? even
> bigger than 1 MB (2048 sectors) ?
> 
> Regards
> 
> -Sven
> 
> 
> 
> 
> On Wed, 2010-07-14 at 13:52 +0200, Milan Broz wrote:
> > On 07/14/2010 01:39 PM, Sven Eschenberg wrote:
> > 
> > > Is there any 'easy' way to access this information. specifically I am
> > > interested, why md would report a 6144 sectors alignment on my 4 disk
> > > raid5 with 512 kb chunks instead of 3072.
> > 
> > Values are in in sysfs also, I am just using topology ioctl which is simpler.
> > 
> > sysfs interface
> > ---------------
> > /sys/block/<disk>/alignment_offset
> > /sys/block/<disk>/<partition>/alignment_offset
> > /sys/block/<disk>/queue/physical_block_size
> > /sys/block/<disk>/queue/logical_block_size
> > /sys/block/<disk>/queue/minimum_io_size
> > /sys/block/<disk>/queue/optimal_io_size
> > 
> > cryptsetup uses minimal/optimal io_size and alignment value
> > to calculate payload offset.
> > 
> > A lot of info here:
> > 
> > http://people.redhat.com/msnitzer/docs/io-limits.txt
> > https://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues
> > 
> > Milan
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] Wrong behavior?

[Milan Broz]

On 07/14/2010 02:07 PM, Sven Eschenberg wrote:
> I don't see why cryptsetup does not end up with 1024 sectors (which is
> the optimal_io_size) - or is the luks header bigger than 512k? even
> bigger than 1 MB (2048 sectors) ?

yes. not header, but space for 8 keyslots.

Alignment is multiple of caclulated size - keyslot takes a lot of space.
Add --debug - you see required alignment there, then code must take
into account keyslots size.

So you have 2048s optimal IO size, I expect you are using 512bit key,
so alignment using default 4k is 4040 sectors (only space for keyslots).

So code must align to next multiple of 2048 - it is 4096.

Milan