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

[Max Vozeler]

Hi all,

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

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

On Tue, Mar 07, 2006 at 03:38:23PM +0100, Jonas Meurer wrote:
> > Yes. For loop-AES we ask about the cipher and type of
> > encryption key. Keysize is implied for each cipher. This is
> > probably different for dm-crypt setups: I suppose it would
> > need to ask about the keysize and volume name, and could
> > ask about hash function - and perhaps other options?
>
> yes, keysize is usually 128, 192 or 256. cipher and type of key are
> also important for dm-crypt and luks. hash might be useful for
> password based encryption with plain dm-crypt.  and for sure a target
> name needs to be supplied, that is given to fstab later.

A keysize question already exists. The others will be easy
to add. So  it would offer these options for now:

 LUKS       volume, cipher, keysize, keytype
 dm-crypt   volume, cipher, keysize, keytype, hash
 
For the cipher choice: partman-crypto uses a directory which
lists the ciphers supported for each type (loop-AES, dm-crypt,
luks) along with options that make sense for them. At some point
we would compile a list of ciphers that should be offered for
plain dm-crypt and LUKS and put information about them into
subdirs of this "ciphers" directory. For example the directory
for plain dm-crypt with aes could look like this:

 ciphers/dm-crypt/aes/
   module  (contains name of required kernel module)
   keysize (contains supported key sizes, each on one line)

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

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

> in other words, for luks you need to luksFormat a partition
> first, and then you can open it with the supplied key/password
> via luksOpen.  for plain dm-crypt there exists no formatting,
> thus partitions can be encrypted with /dev/random directly
> (what is interesting for swap and tmp).

Understood, thanks for explaining!

> > partman-crypto currently knows about two key types: random
> > and keyfile (loop-AES GnuPG-encrypted). It also has
> > provisions for asking for a plain passphrase. Other key types
> > will probably require some new code. crypttab(5) mentions
> > keyfiles; Do you know if they are comparable to loop-AES
> > keyfiles?
>
> 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?

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

> > > - start the decryption, make the decrypted device available
> > > in a way that it can be mounted
> >
> > Yes. I suppose we do the LUKS format at the same time we
> > currently do losetup for loop-AES, then we create a crypttab
> > and do the equivalent of /etc/init.d/cryptdisks start. Am I
> > understanding this correctly?
>
> yes, sounds correct.

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

> 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]

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

cheers,
Max

-- 
[0]
The adversary could - knowing that we use an encrypted stream of
zeroes to intialize the disk - take a block that is unlikely to
contain real encrypted data and use whatever technique he has to
attempt to crack the random one-time key we used. Assuming that
the adversary succeeds at cracking the AES key, it still would't
gain him much: Only the knowledge about which blocks do contain
encrypted data, and which consist only of encrypted zeroes.