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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
