[dm-crypt] miscellaneous dm-crypt/LUKS/cryptsetup questions

[dm-crypt] miscellaneous dm-crypt/LUKS/cryptsetup questions

[Christoph Anton Mitterer]

Hi.

I'd have a number of questions regarding dm-crypt/LUKS/cryptsetup and  
would be happy if some of them could be answered :)


1) With LUKS there's a master key (the one which is decrypted via the  
key-slot-keys and that's actually used to decrypt the payload data).
How is it generated? Via /dev/random or /dev/urandom?


2) They key-files specified via --key-file when creating  LUKS volume  
or adding a new key... is it directly used as the  
master-key-encrypting key or is it somehow hashed and the result is  
used for the actual encryption?
And as a follow-up,.. does it need to have a special size, related to  
the used cipher/mode, or can it be e.g. 1 MB and is simply hashed?


3) Which cipher/mode is the "most secure" one? Perhaps with the  
restriction that AES should be used?
Currently I always use aes-xts-plain.
AFAIK lrw is "borken" or has at least some design issues which is why  
xts was developed, right?
Or is something different better?
Should one use plain with xts or better essiv or even benbi? From what  
I understood how XTS works is, that plain should be just fine and  
essiv/benbi should give no additional security, right?

I guess "best" is to use AES with 256 bits, right? How large has the  
key to be then? I've read somewhere that one needs actually 512 bits  
then for use with XTS.


4) Is the master key only stored at one place on the disk, or at multiple?
Imagine I have some severe disk errors, and the LUKS header is  
completely lost... is the dump as created by luksHeaderBackup enough  
the get decryption working again?


5) I guess it's still true that one should (for security reasons) fill  
the disk with random data before creating the LUKS volume, right?
I guess this is also true, when using SSDs, at least when not using TRIM?

May I suggest that you add a feature to cryptsetup, that when doing a  
luksFormat, the disk is automatically filled with random data, and an  
additional switch to disable it (I guess the default should be to do  
the filling, although it's time consuming... I mean we do the whole  
crpyt-thingy for our paranoia ;) ).


6) Are there plans to at LABEL soupport to the LUKS volumes? I mean  
UUID is already there...


Thanks so far,
Chris.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [dm-crypt] miscellaneous dm-crypt/LUKS/cryptsetup questions

[Milan Broz]

On 05/27/2010 02:51 PM, Christoph Anton Mitterer wrote:

> 1) With LUKS there's a master key (the one which is decrypted via the  
> key-slot-keys and that's actually used to decrypt the payload data).
> How is it generated? Via /dev/random or /dev/urandom?

Currently LUKS master (aka volume) key is generated using /dev/urandom
if not provided in --master-key-file
(see below), I want to add more options for RNG soon.

(My plan was to switch to gcrypt RNG by default but it is not possible,
see https://bugs.g10code.com/gnupg/issue1217 - it is unusable for
default cryptsetup key generator use.)

In some next version I want to make it configurable,
so you can select between /dev/random, /dev/urandom and gcrypt RNG.

(reasons for using urandom was discussed several times here, see archive)

> 2) They key-files specified via --key-file when creating  LUKS volume  
> or adding a new key... is it directly used as the  
> master-key-encrypting key or is it somehow hashed and the result is  
> used for the actual encryption?

No. --key-file is always keyslot passphrase (for LUKS), if you want to specify
master key, you have to use cryptsetup 1.1.x and --master-key-file.
If not specified, RNG is used to generate master key.

(For plain create it is hashed, but it is not question here.)

> And as a follow-up,.. does it need to have a special size, related to  
> the used cipher/mode, or can it be e.g. 1 MB and is simply hashed?

Passphrase length (key to unlock keyslot) from key-file is unlimited,
master-key-file (if used) is directly used as key so it is limited by
algorithm/key size.

> 3) Which cipher/mode is the "most secure" one? Perhaps with the  
> restriction that AES should be used?
> Currently I always use aes-xts-plain.
> AFAIK lrw is "borken" or has at least some design issues which is why  
> xts was developed, right?
> Or is something different better?

Secure against whom? Secure in which environment, with which RNG?
...

> Should one use plain with xts or better essiv or even benbi? From what  
> I understood how XTS works is, that plain should be just fine and  
> essiv/benbi should give no additional security, right?

yes.
(simplifying) XTS mode basically splits key into two parts, one part is
used for generating IV using AES, ESSIV is not needed here.

(and note benbi is just plain IV generator in principle, only endianess differ)

> I guess "best" is to use AES with 256 bits, right? How large has the  
> key to be then? I've read somewhere that one needs actually 512 bits  
> then for use with XTS.

Because of the key split, for XTS mode you must use 256 bit or 512 bits key.
(So internally it will use AES128 or AES256)

> 4) Is the master key only stored at one place on the disk, or at multiple?
> Imagine I have some severe disk errors, and the LUKS header is  
> completely lost... is the dump as created by luksHeaderBackup enough  
> the get decryption working again?

Master key itself is not stored anywhere. It is calculated from passphrase
and keyslot blocks using iterated PBKDF2.

There are no duplicate areas, even loss of one bit in keyslot makes it
unusable.

Using luksHeaderBackup (with passphrase knowledge) is enough to recover it.
(In fact it is just plain snapshot of header and kesylots. So anyone
with only header backup and passphrase knowledge can decrypt the disk later.)

> 5) I guess it's still true that one should (for security reasons) fill  
> the disk with random data before creating the LUKS volume, right?
> I guess this is also true, when using SSDs, at least when not using TRIM?

yes. and TRIM is not yet supported anyway in kernel DM (including dm-crypt).

All devices in stack must support it to work it reliably,
it is similar to topology alignment support - it must propagate through
stack of devices properly.


> May I suggest that you add a feature to cryptsetup, that when doing a  
> luksFormat, the disk is automatically filled with random data, and an  
> additional switch to disable it (I guess the default should be to do  
> the filling, although it's time consuming... I mean we do the whole  
> crpyt-thingy for our paranoia ;) ).

yes, I want to add this, somehow, someday. :)

> 6) Are there plans to at LABEL soupport to the LUKS volumes? I mean  
> UUID is already there...

No plans. Label is usually used together with FS, so after unlocking the disk
you can use label on FS on top of that.

Milan

Re: [dm-crypt] miscellaneous dm-crypt/LUKS/cryptsetup questions

[Christoph Anton Mitterer]

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

On Thu, 2010-05-27 at 15:53 +0200, Milan Broz wrote:
> Currently LUKS master (aka volume) key is generated using /dev/urandom
> if not provided in --master-key-file
> (see below), I want to add more options for RNG soon.
So would it be better for now to do a --master-key-file /dev/random?
Or is this not as secure (as urandom) in this case?

> (My plan was to switch to gcrypt RNG by default but it is not possible,
> see https://bugs.g10code.com/gnupg/issue1217 - it is unusable for
> default cryptsetup key generator use.)
Uhm... I thought you'd only need to do this once,... and probably not
even at system start but then when you do the luksFormat?!

So where's the problem? I mean RNG is not required during normal
operation, is it?


> In some next version I want to make it configurable,
> so you can select between /dev/random, /dev/urandom and gcrypt RNG.
Ah nice...


> (reasons for using urandom was discussed several times here, see archive)
Will try to find it...


> > 2) They key-files specified via --key-file when creating  LUKS volume  
> > or adding a new key... is it directly used as the  
> > master-key-encrypting key or is it somehow hashed and the result is  
> > used for the actual encryption?
> 
> No. --key-file is always keyslot passphrase (for LUKS), if you want to specify
> master key, you have to use cryptsetup 1.1.x and --master-key-file.
> If not specified, RNG is used to generate master key.
Yeah I'm talking about the keyslot passphrase...  but is it directly
taken (in full lenght) or is it hashed again (and the result used to
encrypt the volume key for the slot).


> Passphrase length (key to unlock keyslot) from key-file is unlimited,
> master-key-file (if used) is directly used as key so it is limited by
> algorithm/key size.
And if master-key is automatically generated,.. cryptsetup always
chooses the right lenght!?


> > 3) Which cipher/mode is the "most secure" one? Perhaps with the  
> > restriction that AES should be used?
> > Currently I always use aes-xts-plain.
> > AFAIK lrw is "borken" or has at least some design issues which is why  
> > xts was developed, right?
> > Or is something different better?
> Secure against whom? Secure in which environment, with which RNG?
Well,... good question ^^

"As good as possible, aginst NSA&friends"?! ;)
For the RNG I'd say I use --master-key-file /dev/random as long as
gcrypt support is not possible..
Environment: HDD or SSD that can be (in principle) stolen by anyone.


btw: The
Hash spec: sha1
from luksDump... how is it used when having aes-xts-plain? Is it at all
or is it just a "default-unset-value"?


> > I guess "best" is to use AES with 256 bits, right? How large has the  
> > key to be then? I've read somewhere that one needs actually 512 bits  
> > then for use with XTS.
> Because of the key split, for XTS mode you must use 256 bit or 512 bits key.
> (So internally it will use AES128 or AES256)
So either by setting -s 256 or -s512 respectively



> > 4) Is the master key only stored at one place on the disk, or at multiple?
> > Imagine I have some severe disk errors, and the LUKS header is  
> > completely lost... is the dump as created by luksHeaderBackup enough  
> > the get decryption working again?
> Master key itself is not stored anywhere.
Of course,... 
>  It is calculated from passphrase
> and keyslot blocks using iterated PBKDF2.
... I meant: Are the keyslots only stored in the beginning,.. or like a
super block at different places...

> There are no duplicate areas, even loss of one bit in keyslot makes it
> unusable.
... ok. I see. So one should probably backup it (very securely).


> (In fact it is just plain snapshot of header and kesylots. So anyone
> with only header backup and passphrase knowledge can decrypt the disk later.)
Well that shouldn't be a problem, is it? I mean if he get's the disk,
he'll have it anyway.


> > May I suggest that you add a feature to cryptsetup, that when doing a  
> > luksFormat, the disk is automatically filled with random data, and an  
> > additional switch to disable it (I guess the default should be to do  
> > the filling, although it's time consuming... I mean we do the whole  
> > crpyt-thingy for our paranoia ;) ).
> yes, I want to add this, somehow, someday. :)
Great :)


> > 6) Are there plans to at LABEL soupport to the LUKS volumes? I mean  
> > UUID is already there...
> No plans. Label is usually used together with FS, so after unlocking the disk
> you can use label on FS on top of that.
Of course,.. but one needs to specify the LUKS device
in /etc/crypttab,... which is right now only possible via device,
by-uuid, by-path, but not by-label.
And I guess this would be a nice feature,.. an consistent with the fact
that LUKS is like a filesystem (or container) to many userspace tools.


Thanks again,
Chris.

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

Re: [dm-crypt] miscellaneous dm-crypt/LUKS/cryptsetup questions

[Milan Broz]

On 05/27/2010 04:20 PM, Christoph Anton Mitterer wrote:
> On Thu, 2010-05-27 at 15:53 +0200, Milan Broz wrote:
>> Currently LUKS master (aka volume) key is generated using /dev/urandom
>> if not provided in --master-key-file
>> (see below), I want to add more options for RNG soon.
> So would it be better for now to do a --master-key-file /dev/random?
> Or is this not as secure (as urandom) in this case?

--master-key-file intentionally can read only regular file.

(read from /dev/random can return if there is not enough entropy, it needs
implement some more code to use.)

> 
>> (My plan was to switch to gcrypt RNG by default but it is not possible,
>> see https://bugs.g10code.com/gnupg/issue1217 - it is unusable for
>> default cryptsetup key generator use.)
> Uhm... I thought you'd only need to do this once,... and probably not
> even at system start but then when you do the luksFormat?!

Sure. The problem is in  automated installations which calls luksFormat.
Switching to gcrypt RNG make them unusable (gathering 300 bytes of real entropy
just to initialize RNG can take hours in this environment.
Of course reading urandom can be another problem here.)

That's why I want to make it configurable - if you want use it,
it will ask you to generate some entropy by moving mouse etc.


>>> 2) They key-files specified via --key-file when creating  LUKS volume  
>>> or adding a new key... is it directly used as the  
>>> master-key-encrypting key or is it somehow hashed and the result is  
>>> used for the actual encryption?
>>
>> No. --key-file is always keyslot passphrase (for LUKS), if you want to specify
>> master key, you have to use cryptsetup 1.1.x and --master-key-file.
>> If not specified, RNG is used to generate master key.
> Yeah I'm talking about the keyslot passphrase...  but is it directly
> taken (in full lenght) or is it hashed again (and the result used to
> encrypt the volume key for the slot).

Read man page - notes on password processing and LUKS documentation,
both is described there;-)

 
>> Passphrase length (key to unlock keyslot) from key-file is unlimited,
>> master-key-file (if used) is directly used as key so it is limited by
>> algorithm/key size.
> And if master-key is automatically generated,.. cryptsetup always
> chooses the right lenght!?

master key length is defined by used algorithm (and -s switch and
compiled-in defaults)

> btw: The
> Hash spec: sha1
> from luksDump... how is it used when having aes-xts-plain? Is it at all
> or is it just a "default-unset-value"?

This is LUKS (keyslot) hash algorithm used (together with PBKDF2) when
unlocking keyslot.
(see documentation again, project site http://code.google.com/p/cryptsetup/
-> Specification)


>>> 4) Is the master key only stored at one place on the disk, or at multiple?
>>> Imagine I have some severe disk errors, and the LUKS header is  
>>> completely lost... is the dump as created by luksHeaderBackup enough  
>>> the get decryption working again?
>> Master key itself is not stored anywhere.
> Of course,... 
>>  It is calculated from passphrase
>> and keyslot blocks using iterated PBKDF2.
> ... I meant: Are the keyslots only stored in the beginning,.. or like a
> super block at different places...

In the beginning only (see luksDump, payload offset in sectors - everything
before that offset is LUKS, after is encrypted data area)

>> (In fact it is just plain snapshot of header and kesylots. So anyone
>> with only header backup and passphrase knowledge can decrypt the disk later.)
> Well that shouldn't be a problem, is it? I mean if he get's the disk,
> he'll have it anyway.

With old backup, he can decrypt disk even with already deleted/changed
keyslot passphrase.

Milan

Re: [dm-crypt] miscellaneous dm-crypt/LUKS/cryptsetup questions

[Mario 'BitKoenig' Holbe]

Milan Broz <mbroz@redhat.com> wrote:
> (read from /dev/random can return if there is not enough entropy, it needs

Nope. It blocks.

> On 05/27/2010 04:20 PM, Christoph Anton Mitterer wrote:
>> Yeah I'm talking about the keyslot passphrase...  but is it directly
>> taken (in full lenght) or is it hashed again (and the result used to
>> encrypt the volume key for the slot).
> Read man page - notes on password processing and LUKS documentation,
> both is described there;-)

Hmmmm, yes - but ... well ... :)

Plain cryptsetup without LUKS uses hashing to derive a key from a
pass-phrase but not from a key-file where it takes the data directly as
key. That's why
	cryptsetup --key-file=/tmp/key create foo /dev/loop0
and
	cryptsetup --key-file=- create foo /dev/loop0 < /tmp/key
are *not* equivalent (in simple terms, you cannot simply write your
pass-phrase to a file and give that to cryptsetup as key-file).

LUKS always uses PBKDF2 to derive the master-key from the key-material.
PBKDF2 is (simplified!) somewhat like a hash function for pass-phrases.
Thus, cryptsetup with LUKS doesn't need to hash a pass-phrase
explicitely and doesn't. That's why
	cryptsetup luksOpen --key-file=/tmp/key /dev/loop0 foo
and
	cryptsetup luksOpen --key-file=- /dev/loop0 foo < /tmp/key
*are* equivalent (with LUKS you can simply write your pass-phrase to a
file and give that to cryptsetup as key-file).


regards
   Mario
-- 
Good, Fast, Cheap: Pick any two (you can't have all three).
                                            -- RFC 1925, 7a

Re: [dm-crypt] miscellaneous dm-crypt/LUKS/cryptsetup questions

[Milan Broz]

On 05/27/2010 06:21 PM, Mario 'BitKoenig' Holbe wrote:
> Milan Broz <mbroz@redhat.com> wrote:
>> (read from /dev/random can return if there is not enough entropy, it needs
> 
> Nope. It blocks.

yep, you are right :)

The problem is that can wait very long time, so it should inform user that system
is out of entropy and ask for some action etc.
This should be part of the RNG handler in cryptsetup if using /dev/random is supported.

Milan

Re: [dm-crypt] miscellaneous dm-crypt/LUKS/cryptsetup questions

[Roscoe]

I think we should have more discussion regarding MK material generation.

Perhaps presenting everyone's ideas for options somewhere, then asking
for advice
from suitably qualified individuals (Peter Gutman?).

-- Roscoe


On Fri, May 28, 2010 at 4:21 AM, Milan Broz <mbroz@redhat.com> wrote:
> On 05/27/2010 06:21 PM, Mario 'BitKoenig' Holbe wrote:
>> Milan Broz <mbroz@redhat.com> wrote:
>>> (read from /dev/random can return if there is not enough entropy, it needs
>>
>> Nope. It blocks.
>
> yep, you are right :)
>
> The problem is that can wait very long time, so it should inform user that system
> is out of entropy and ask for some action etc.
> This should be part of the RNG handler in cryptsetup if using /dev/random is supported.
>
> Milan
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] miscellaneous dm-crypt/LUKS/cryptsetup questions

[Arno Wagner]

On Thu, May 27, 2010 at 08:21:11PM +0200, Milan Broz wrote:
> On 05/27/2010 06:21 PM, Mario 'BitKoenig' Holbe wrote:
> > Milan Broz <mbroz@redhat.com> wrote:
> >> (read from /dev/random can return if there is not enough entropy, it needs
> > 
> > Nope. It blocks.
> 
> yep, you are right :)
> 
> The problem is that can wait very long time, so it should inform user that
> system is out of entropy and ask for some action etc. This should be part
> of the RNG handler in cryptsetup if using /dev/random is supported.

Indeed. You could also just flush an explanation to stdout and ask
the user to provide keystrokes if things take long. That would 
remove the need for monitoring what comes from /dev/random.
Maybe use this as a temporary fix that amounts to one printf.

However that does not solve the case of automatic installation
on, e.g., embedded devices that have a low-entropy envoronment.

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] miscellaneous dm-crypt/LUKS/cryptsetup questions

[Mario 'BitKoenig' Holbe]

Arno Wagner <arno@wagner.name> wrote:
> However that does not solve the case of automatic installation
> on, e.g., embedded devices that have a low-entropy envoronment.

well, such install-systems could have a look at the entropy available
before choosing a specific source of randomness (not that there would be
a good one on such systems :)).


regards
   Mario
-- 
The question of whether a computer can think is no more interesting than
the question of whether a submarine can swim.          -- E. W. Dijkstra

Re: [dm-crypt] miscellaneous dm-crypt/LUKS/cryptsetup questions

[Milan Broz]

On 05/28/2010 09:39 AM, Mario 'BitKoenig' Holbe wrote:
> Arno Wagner <arno@wagner.name> wrote:
>> However that does not solve the case of automatic installation
>> on, e.g., embedded devices that have a low-entropy envoronment.
> 
> well, such install-systems could have a look at the entropy available
> before choosing a specific source of randomness (not that there would be
> a good one on such systems :)).

Various systems (installed from net/PXE) which have enough entropy to
generate master key for LUKS disk (or at least to properly seed some pseudo RNG),
have not enough entropy to seed gcrypt very-strong-RNG
(it _requires_ 300 bytes /dev/random data to seed).

And because the system is usually headless, waiting in installer/luksFormat
with possible no network activity at the moment, it can wait forever.

(My example was about some install verification system, where
the quality of the long term key was not important. Everyone probably
see here possible problem with not enough entropy in generated
key in general in such installations...)

Milan

Re: [dm-crypt] miscellaneous dm-crypt/LUKS/cryptsetup questions

[Christoph Anton Mitterer]

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

On Thu, 2010-05-27 at 16:45 +0200, Milan Broz wrote:
> > So would it be better for now to do a --master-key-file /dev/random?
> > Or is this not as secure (as urandom) in this case?
> 
> --master-key-file intentionally can read only regular file.
> 
> (read from /dev/random can return if there is not enough entropy, it needs
> implement some more code to use.)
Is it then secure (an better than using /dev/urandom) to do something
like:

mount -t tmpfs foo /mnt
cd /mnt
dd if=/dev/random of=mk bs=1 count=64
cryptsetup --master-key-file mk -s 512 -c aes-xts-plain --key-file
someKeyFile luksFormat /dev/blafasl

?
The master key should not be leaked to disk,... it 64 bytes large, and a
keyfile is used to encrypt it.

Or better stick with urandom?

 
> Sure. The problem is in  automated installations which calls luksFormat.
Are automated installations really a target audience for cryptsetup?
Either the keyfile/passphrase has to be automatically copied during
installation (which sounds after insecurities to me) or manual user
input (passphrase) is required anyway...
And I'd suggest, even for automated installations one should per default
use a blocking /dev/urandom or libgcrypt... and only manually via
command line switch, the change to urandom should be possible (not
automatically after e.g. 4 mins blocking)


> That's why I want to make it configurable - if you want use it,
> it will ask you to generate some entropy by moving mouse etc.
Sounds nice :)

 
> > btw: The
> > Hash spec: sha1
> > from luksDump... how is it used when having aes-xts-plain? Is it at all
> > or is it just a "default-unset-value"?
> 
> This is LUKS (keyslot) hash algorithm used (together with PBKDF2) when
> unlocking keyslot.
> (see documentation again, project site http://code.google.com/p/cryptsetup/
> -> Specification)
Can/should I change it to something "better" (e.g. SHA512)?
I guess this could be done by simply exchanging the key slots and I do
not have to reencrypt the whole disk?


> >> (In fact it is just plain snapshot of header and kesylots. So anyone
> >> with only header backup and passphrase knowledge can decrypt the disk later.)
> > Well that shouldn't be a problem, is it? I mean if he get's the disk,
> > he'll have it anyway.
> With old backup, he can decrypt disk even with already deleted/changed
> keyslot passphrase.
Of course,.. but that's always the case,... whether I've backuped the
header or not.... once an attacker was able to copy the material,..
he'll be able to access it as soon as the algo is weak/broken.


Cheers,
Chris.

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

Re: [dm-crypt] miscellaneous dm-crypt/LUKS/cryptsetup questions

[Christoph Anton Mitterer]

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

On Thu, 2010-05-27 at 18:21 +0200, Mario 'BitKoenig' Holbe wrote:
> LUKS always uses PBKDF2 to derive the master-key from the key-material.
I've always thought the master key is stored in encrypted form in the
key-slots.
And the key derived by the passphrase/key-file via PBKDF2 is used as key
for the encryption of that?


Cheers,
Chris.

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

Re: [dm-crypt] miscellaneous dm-crypt/LUKS/cryptsetup questions

[Milan Broz]

On 05/28/2010 12:56 PM, Christoph Anton Mitterer wrote:
> On Thu, 2010-05-27 at 16:45 +0200, Milan Broz wrote:
>>> So would it be better for now to do a --master-key-file /dev/random?
>>> Or is this not as secure (as urandom) in this case?
>>
>> --master-key-file intentionally can read only regular file.

master-key-file is new option which allows using pre-generated master key.

Please use it only if you must - it was designed for Key Escrow functions,
(which uses libcryptsetup directly anyway) not for normal use.

>>
>> (read from /dev/random can return if there is not enough entropy, it needs
>> implement some more code to use.)
> Is it then secure (an better than using /dev/urandom) to do something
> like:
> 
> mount -t tmpfs foo /mnt
> cd /mnt
> dd if=/dev/random of=mk bs=1 count=64
> cryptsetup --master-key-file mk -s 512 -c aes-xts-plain --key-file
> someKeyFile luksFormat /dev/blafasl
> 
> ?
> The master key should not be leaked to disk,... it 64 bytes large, and a
> keyfile is used to encrypt it.
> 
> Or better stick with urandom?

See above, do not use it at all just run luksFormat in your case which
generate key from /dev/urandom.

>> This is LUKS (keyslot) hash algorithm used (together with PBKDF2) when
>> unlocking keyslot.
>> (see documentation again, project site http://code.google.com/p/cryptsetup/
>> -> Specification)
> Can/should I change it to something "better" (e.g. SHA512)?
> I guess this could be done by simply exchanging the key slots and I do
> not have to reencrypt the whole disk?

First read archive discussion about that - there is no problem with SHA1 in this use.
You can define hash during luksFormat (-h <alg>) with cryptsetup 1.1.x, but if you select
somethin other than sha1, it will be incompatible with old distros.

You cannot change it later (only by reformatting header).

Milan

Re: [dm-crypt] miscellaneous dm-crypt/LUKS/cryptsetup questions

[Mario 'BitKoenig' Holbe]

Christoph Anton Mitterer <christoph.anton.mitterer@physik.uni-muenchen.de> wrote:
> I've always thought the master key is stored in encrypted form in the
> key-slots.
> And the key derived by the passphrase/key-file via PBKDF2 is used as key
> for the encryption of that?

Yes, of course.


regards
   Mario
-- 
Unfortunately, the chip vendors have delayed the availability of the
long-promised crystal-ball peripherals yet again, forcing the governor
code to rely on heuristics; once again, software must make up for
deficiencies in the hardware.                  -- Jonathan Corbet, LWN

Re: [dm-crypt] miscellaneous dm-crypt/LUKS/cryptsetup questions

[Arno Wagner]

On Fri, May 28, 2010 at 12:56:15PM +0200, Christoph Anton Mitterer wrote:
> Can/should I change it to something "better" (e.g. SHA512)?

No. SHA1 is not broken for this use at all. 

There are indications that SHA1 may have collisions that can be 
practically found, but for SHA1 to be broken as a password hasher 
(with the hash value being secret), it would need to have low output 
entropy. This is about the easiest thing to get right in crypto
hash design and in fact does not even need a crypto hash at all
to be secure. 

You may be thinking of the case where the hash output is known
and an attacker tries to guess a hash input that produces the
same hash output. This is not the situation with LUKS, since
an attacker that has the hash output can already open the
LUKS encryption. Hence the hash output is also secret and stored
nowhere in the system, unless the LUKS device is open, in
which case the attacker can simply access its contents.

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