Re: Status of partman-crypto

[Max Vozeler <max@decl.org>]

Hey Frans and everyone,

On Fri, Dec 09, 2005 at 12:29:44PM +0100, Frans Pop wrote:
> Could you please provide some info on the status of partman-crypto?

I have started a Wiki-Page last night to track development of
partman-crypto and related packages. It may already answer
some parts of your questions:

  http://wiki.debian.org/DebianInstallerCrypto

> - How far along is the udeb itself?

This is difficult to answer ;-)

I've been using the code occasionally for tests and for a 
handful of real installs. In terms of working, it seems OK.
There are a couple of hard remaining problems though:

 - Usuability is quite bad, nevermind what I tried. Setting
   up encrypted partitions requires _many_ steps (not counted)
   and is actually quite tiresome. Lots of improvements are
   possible here, perhaps from feedback of users of a beta.

 - There is very little entropy in the kernel's pool when we
   get to create encryption keys. As we need 2925 bytes of
   strongly random keydata for loop-AES, some way is needed to
   get more entropy or the process takes forever. 

   The code that's currently in SVN has a very limited approach
   to this problem. It requires the user to enter large amounts
   of random characters on the keyboard into a debconf string
   template without good feedback on the progress.

   A slightly better approach is what I'm including in custom
   images currently: A cdebconf plugin that shows a password
   type screen along with a progressbar. It opens a FIFO for
   writing out the keydata to the caller and shows via the
   progressbar how many percent of the required data have been
   read already from /dev/random.
 
   This plugin (cdebconf-plugin-entropy) is currently built
   from inside a cdebconf tree. Much better would be some way to
   build the plugin using a cdebconf-plugin-dev package or so.
   But even with this plugin, the entropy of entered data is
   not very high and takes many many keypresses by the user.

   So, from a usability perspective, one remaining blocker is
   definitely to find better sources of entropy. Current ideas
   floating around: (None implemented AFAIK): 
   
     - Use hw_random kernel module where available (fragile, 
       detection is poor and may hang indefinitely when there 
       is no hardward RNG available). May require use of rngd
       daemon from rng-tools.

     - Try to detect and load audio hardware. Needs some
       experimenting to see whether kernel pool is only fed 
       when recording is enabled.
 
     - Try to detect and load mouse interface. This will be
       much easier in g-i. Requires the user to make random
       mouse movements, clicks, etc. Perhaps in addition to
       keyboard input.

     - Recommend users to create keyfiles on another system
       with sufficiently filled randomness pool and only fall
       back to creating in d-i when the user can't/doesn't do
       that. This solution would require a way to load keyfiles 
       from removable media.

   I hope to find time this weekend to document this problem
   on the DebianInstallerCrypto Wiki-Page.

> - What needs to be done before it can be uploaded?

Other than the above considerations, there are currently two
external blockers for creating loop-AES keyfiles: A uuencode
binary is needed to encode the keydata and gnupg-udeb is needed
to encrypt it into a keyfile.

Apart from that all required components are in place. Building
loop-AES kernel modules still needs some work on archs other than
i386, powerpc and sparc. Bugs for the problems I encountered are
reported and will hopefully be solved sometime soon.

Lastly, and most importantly, I'm very cautious about the data
security in partman-crypto and would like to find one or more
experienced cryptographers to review the implementation before
releasing it for general use. (This does not necessarily block
inclusion in a beta release, but there will need to be a very
visible warning for users not to rely on the encryption.)

> I'm asking because we listed partman-crypto as one of the goals for the 
> Etch Beta2, but of course that can only happen if its uploaded...

More people are getting involved in partman-crypto now, so I'm
actually quite optimistic that we can make it for beta2.

Have you already planned a timeframe for beta2 feature-freeze/
release? I can't really predict how much time I'll have available
to work on partman-crypto before ~ 03/2006 unfortunately, so it
would be good to know which timeframe we are talking about.

I hope to find time this weekend to update TODO and to build a
new snapshot mini.iso of the current code. This will give a
better overview of which areas still need work.

cheers,
Max