Hi all, On Thu, Mar 09, 2006 at 05:22:07PM +0100, Jonas Meurer wrote: > On 07/03/2006 Max Vozeler wrote: > > 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.
When you do, please try a newer snapshot instead of the one above. That one had a couple of problems. I've uploaded a new snapshot (20060310) that also includes the cdebconf newt plugin for helping the entropy collection. (cdebconf-newt-entropy) http://nusquama.org/~max/d-i/20060310/crypto-mini.iso There are already two errata items for this snapshot: Partition erase is broken: It consumes lots and lots of memory and can cause the OOM killer to step in. Make sure to select "Erase data: no" for the encrypted partitions for now. The second erratum concerns the installed system. fstab still ends up with 2 in fs_passno for encrypted loop partitions. Of course it can't fsck the encrypted backing device and so the boot fails with an error. You can choose ^D to continue and change passno to 0 afterwards. > 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. I will add provisions for the missing key types shortly. Using keyfiles that the user provides on removable media is still an unsolved problem, but one I'd eventually like to attack. There are use cases apart from working around the low-entropy problem where using an existing keyfile makes a lot of sense - for example when it should be pubkey encrypted. Thinking about it and relating to Frans reply - it seems to me that loading keyfile from removable media has much in common with loading extra (non-free or updated) udebs and firmware files for use by the installer. Perhaps a solution for one use could help solve the other use too. > [explanations about keyfiles] Again many thanks for explaining. > 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. That would be excellent! > > 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. One advantage of gnupg keyfiles over openssl keyfiles is that they can also be encrypted asymmetrically for one or more perhaps already existing keys. But openssl keyfiles are also very good.. For loop-AES setups there is an extra advantage from using gnupg keyfiles: root can encrypt the keyfile to one or more users so they can access the encrypted partition without getting access to the encryption keys used, which can later be revoked. (Only as an aside - this is not directly relevant :-) > > 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. Yes. We can do that for cryptsetup setups - no problem. > then we still need libgcrypt11, libgpg-error0, libpopt0, > libuuid1, dmsetup and cryptsetup. > > i'll look into it soon. I think libuuid1 and also dmsetup are already built as udebs. If you need any help with this, I'm sure people on debian-boot would be able and happy to help. As would I. > 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. Ah, I must have misunderstood. I think we are in perfect agreement then :-) > 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. Sounds very good to me! I will continue to send you questions when they come up and let you know about things that we/you can already do to prepare cryptsetup support. cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
