Installer doesn't wipe the disk when installing on encrypted LVM

[Vadim]

In Jaunty Beta, when installing using the encrypted LVM option, the disk partitioning step proceeds far too quickly.

A proper disk encryption setup should involve overwriting the whole disk with /dev/urandom. Otherwise, it's easy for an attacker to tell which parts of the disk were written to, and possibly deduce useful information from that.

Also, somebody who wants to encrypt their disk will almost certainly find the possibility of an attacker recovering pre-encryption data very undesirable.

If the time to do this is too long, a compromise would be the installer asking the user whether the disk should be cleared, defaulting to "Yes". This could be also useful for users who cleared the disk on their own before running the installer.

[Vadim (d-launchpad-vadim-ws)]

Additional thing I noticed: The install CD doesn't ship the intel-rng and amd-rng kernel modules, which hugely accelerate the generation of random numbers on the computers that include the required hardware.

For best performance, the installer should try to load those modules before doing the disk wipe.

[Colin Watson (cjwatson)]

We tried doing exactly this by default back in 7.10 pre-release, and everyone complained because it was ridiculously slow. One tester reported that it took seven hours to wipe his 800GB disk!

The option of whether to securely erase the disk is already available in manual partitioning, but I agree that it ought to be offered in automatic partitioning as well.

I agree that it would make sense to load the rng modules, but I'd prefer to consider that as a separate bug. Please file a bug on the 'linux' package in Ubuntu to have the rng modules added to the udebs (installer modules) that the kernel ships, and use the "Also affects distribution" link to create a task on the 'partman-crypto' package as well.

[Vadim (d-launchpad-vadim-ws)]

Yes, I went through this manually and it *is* ridiculously slow.

However, it doesn't have to be. I googled around and came up with people complaining about the slowness of /dev/urandom in LKML. The reply was that urandom isn't really intended for this sort of usage, and the suggested workaround is to use it to initialize a PRNG and use that as a source of random data to wipe the disk.

If there's no tool that currently does this, it should be possible to write one easily enough.

In any case, at the very least, a quick, non-cryptographic strength overwriting of the whole disk should be supported, to avoid the possibility of recovery of any pre-encryption data.