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

[Max Vozeler]

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