Re: cgd(4) ciphers

On 10/2/13 7:18 PM, Roland C. Dowdeswell wrote:
[---]
> The reason that we have configuration files rather than putting a
> few bytes at the start of the disk is that you can keep the config
> files separately from the disk in question which gives you various
> advantages.  E.g. you can frustrate dictionary attacks against a
> lost external USB disk if your parameter file is not stored on it
> but rather only on the laptop onto which it is usually plugged.

   Agreed. I hope no one redesigns cgd to do away with the parameter
files. I reuse them, I back them up, I move them around to different
devices.

> The params files also have options such as simply storing the key
> for the above USB disk case or other similar cases.  You can also
> set it up to fetch keys from a key server via the ``shell_cmd''
> key generation method for unattended booting of a server with an
> encrypted disk.  None of these use cases can be accomodated with
> a few bytes at the start of the volume read in by the boot blocks.

   This. Plus two. Squared.

> Back to being serious, we could easily support boot-block crypto
> (not full disk) via various mechanisms.  I haven't done it as I
> have not had the need for it.  If we do it, though, I would ask
> that we leave the existing framework in place as I find it useful
> to be able to setup things that are a little more complicated on
> occasion.

   A long time ago (branched from
http://netbsd.sonnenberger.org/info/7e62d1746a) I wrote a small patch which:
   - made cgd use raw disk access during early init
   - configure a cgd device on top of a "raw root" device
   - configured root on the cgd device
   - once root had been configured, cgd was reconfigured to use regular
disk operations.

   Everything lived in the kernel, which was loaded from a USB memory
stick, and I wrote a small cgd configuration file parser which parsed a
conf-buffer during early initialiation.

   It was very simple really; I had full-disk encryption without using
the init.chroot hack (In fact, I started working on an alternative to
full-disk encryption because the init.chroot hack stopped working when I
switched to amd64).

   And it didn't require any resedign of how cgd parameters are stored/used.

   /Jan