[Pkg-cryptsetup-devel] Re: Status of partman-crypto

[Jonas Meurer]

On 07/03/2006 Max Vozeler wrote:
> Jonas, I'm going into some details about partman-crypto and
> detailed questions about dm-crypt and LUKS. I hope you don't
> mind that I bombard you with questions like this... :-)

no problem :-)

> I've uploaded a snapshot of partman-crypto in form of a bootable
> mini.iso image so you can see what it currently looks like:
> http://nusquama.org/~max/d-i/20060307/crypto-mini.iso

great, i'll give it a try during the next days.

> > > This is the part I'm most clueless about. :-)
> > > Which key types are supported and which are recommended
> > > for dm-crypt and LUKS respectively?
> >
> > what do you mean with key types? random keys are only supported
> > by dm-crypt, luks requires a persistent key. but appart from
> > that, i don't know of any limits. you can use whatever file you
> > like as a key. binary, text, and also random data.
> 
> To illustrate, the user will be presented with a dialog that
> looks roughly like this:
> 
>   Use as:	Device-mapper encryption (dm-crypt)
>   Encryption:	<cipher>
>   Key size:	<key size>
>   Key type:	<key type>
> 
>   Use as:	Device-mapper encryption (LUKS)
>   Encryption:	<cipher>
>   Key size:	<key size>
>   Key type:	<key type>
> 
> I wonder which choices make sense to offer for the "Key type"
> option with LUKS and with plain dm-crypt respectively. From what
> I learned until now, I think the choices would be "random" and
> "passphrase" for plain dm-crypt and just "passphrase" for LUKS.
> Both dm-crypt and LUKS I think accept a plain passphrase and
> take care of hashing themselves.

i would add keyfile. random, passphrase and keyfile for dm-crypt,
passphrase and keyfile for luks. keyfile should be a file that the user
provides, or it should be created during the installation.

> To put my question in a different way: cryptsetup can use a
> passphrase and be told to use a random key. Are there other ways
> to produce keys that cryptsetup can use? For keyfiles, for
> example, how are they stored and made available to cryptsetup on
> the installed system? This probably again shows my lack of
> knowledge about both systems :-)

the keyfiles are provides through the filesystem. i may store a key in
/etc/keys/mykey. or i can store it on a usbstick, flashcard, cdrom,
floppy, whatever. cryptsetup currently has no facilities to support
removable media, but theoretically all this is possible.

> > i don't know what loop-AES keyfiles are, but for dm-crypt and
> > luks any random file can be used as key. the more random it's
> > content is, the more secure it is. so when users choose to
> > create a key file instead of using an existant one, i'dd
> > suggest to use 'dd if=/dev/random of=keyfile'.
> 
> This actually seems similar to loop-AES. So another stupid
> question from me :-) Can dm-crypt/LUKS setups be used with
> keyfiles in encrypted form (eg. using openssl or gnupg) and can
> /etc/crypttab be setup so that the user will be asked for a
> passphrase to decrypt the keyfile?

a wishlist bug against crypsetup adds support for openssl encrypted
keys. i planned to do some work related to this task within the next
weeks.

> For loop-AES it works like this: Actual encryption keys are
> created from /dev/random and then encrypted using gnupg and a
> passphrase (or a public key). When the system starts, mount or
> losetup call gnupg to decrypt the keyfile and use the keys
> therein to setup the loop encryption.

it's no problem to implent this in cryptsetup packages as well.

> It seems to me that, if it's possible, it would be preferred
> to use encrypted keyfiles. They have the advantage that the
> actual encryption keys are strongly random (as in /dev/random)
> while users need only memorize a passphrase that they can 
> choose and change.

ok, so you mean that the key for actually encrypting the disk is more
secure than a simple passphrase. i would also like to support
unencrypted keys, stored on removable media, but this needs some more
work to be done.

> Cool - this should all not be difficult to do. The part that
> probably involves most work is to build udeb versions of
> cryptsetup and the libraries it uses. It think some parts do
> already exist as udebs (libdevmapper?).

then we still need libgcrypt11, libgpg-error0, libpopt0, libuuid1,
dmsetup and cryptsetup.

i'll look into it soon.

> > but /dev/zero is not really a good source for random data, is
> > it? even /dev/urandom is considered as insecure, so i'dd rather
> > try to give /dev/random more entropy instead of using less
> > secure sources.
> 
> The way I understand it we don't need the data that is written
> to be strongly random. For loop-AES - I suppose it's similar for
> dm-crypt - the initialization is used to make it more difficult
> for an adversary to see which blocks actually contain encrypted
> data and are worth trying to crack. If the data is indisting-
> uishable from random data, it should do. [0]

no, i don't mean filling the device with random data before encrypting
it. this is recommented too, and could be provided as an option function
in the installer. but what i meant here is creating the keys with data
from /dev/random.

> > yes, the cryptsetup package in debian/unstable supports both,
> > plain dm-crypt and luks. luks partitions are configured via the
> > 'luks' option in /etc/crypttab. if this option is not present,
> > cryptsetup treats the partition as a plain dm-crypt one.
> 
> Thanks for explaining all this. I've started to to look through
> the documentation today and tried out cryptsetup in a few test
> setups. I'm slowly getting a better understanding..

great ;-)

if you've any work that could be done by us (the cryptsetup maintainer
team), let us know.

next tasks will be:
- add support for gnupg/openssl encrypted keys to cryptdisks
- add support for removable devices to cryptdisks
- add udebs for cryptsetup and its dependencies.

...
 jonas