partman-crypto adds support to DebianInstaller for configuring, setting up and installing onto encrypted block devices. It allows users to setup loop-AES, dm-crypt and LUKS encrypted partitions for their Debian system during installation.

partman-crypto is intended to use secure defaults while allowing experienced users to change settings as they require.

Status

partman-crypto is included in the installer since Debian Etch (4.0).

Support for plain dm-crypt, LUKS and loop-AES is mostly complete and tested. The current focus is on testing the existing features, fixing known bugs and on improving usability. Bugs and feature requests are tracked on the partman-crypto BTS page.

Resources

Ideas, Features, Problems

This sections is about ideas, feature requests, known problems and how those could be solved/implemented/etc. Feel free to add any features that you'd like to see.

Key generation / Lack of entropy

Encryption keys for loop-AES (and random keys for dm-crypt) are created from /dev/random. It is important that we have a good source of entropy to allow us to extract the required a mount of key data from /dev/random (each loop-AES v3 key requires 2925 bytes of random data). Currently the low amount of entropy in the kernel pool causes the key generation to block for a long time.

There are some ideas for how to solve this:

Don't create keys from inside d-i; Ask users to create them on another system and provide them to partman-crypto on a removable device.

Ask the user to type randomly on the keyboard. This is done by cdebconf-entropy. It turned out that typing alone requires too many key presses to be user-friendly. The plugin is still used to show a progressbar during key creation.

Use a hardware RNG if available. One problem with doing this is that not many systems actually have a usable hardware RNG and that detecting them is very difficult. There is also the issue of bad HWRNGs that produce low-quality output. Packages like rng-tools implement FIPS-140-2 tests before feeding the kernel pool to protect against this.

Use non-RNG hardware devices that may produce random output. Examples of this are audio and video devices which can be sourced using audio-entropyd or video-entropyd. Here the problem of low-quality randomness exists as well.

The current idea is to check if rngd (package rng-tools) could be extended to read from one or more FIFOs and character devices, do FIPS tests and feed the kernel entropy pool. If this is feasible audio-entropyd, video-entropyd, software for collecting network traffic timings etc. could be packaged and be made to feed rngd. TODO: Ask the maintainer of rng-tools (hmh@d.o) if this approach is sound and practically feasible.