Re: Re: [patch] cgd

[Taylor R Campbell <campbell+netbsd%mumble.net@localhost>]

   Date: Wed, 1 Dec 2010 23:57:45 +0000
   From: "Roland C. Dowdeswell" <elric%imrryr.org@localhost>

   I'm reviewing the patch and it looks mostly good.  I've checked in
   a couple of the bits already and will check the rest in with only
   cosmetic modifications (such as breaking the patch into separate
   commits implementing single changes) over the course of the next
   few hours.

Great, thanks!

   On the documentation, did you have a look at the NetBSD Guide as
   well?  That's written from a different perspective and that might
   be helpful.

I did.  The chapter in the NetBSD Guide walks the reader through the
steps to set up cgd on a disk, and the steps to set up encrypted swap
space, which is helpful.  But before using any cryptographic software,
I want to be absolutely sure I understand exactly what it is doing for
me, what I can tell it to do, and how -- at least, as well as a non-
cryptographer can understand that.

What the Guide doesn't do is specify precisely the format of the data
on disk (which I want to know in case I want to recover my disk from a
non-NetBSD system), or precisely what each cgdconfig incantation means
(in more detail than just that it is a step in setting up an encrypted
disk or swap).  It also doesn't precisely describe the properties that
parameters files can have, or discuss many of the cryptographic
properties of cgd.  The man pages are probably better places for this
information anyway.

   It was a very conscious decision to ensure that the cgd parameters
   file does not contain enough information to validate that a passphrase
   is actually correct.  This decision was made to allow you to place
   the params file on separate media, e.g. a USB dongle or a separate
   disk, and rest assured in the knowledge that mere possession of
   the parameters file would not allow a dictionary attack to proceed.

Understandable.  This has the danger that corruption of the parameters
file will not be detected, and instead will probably lead to the user
tearing his hair out trying to remember his pass phrase.  (An attacker
might do this deliberately as a `denial of hair (or service)' attack:
flip a bit in the user's salt.  A spinning magnetic platter might do
this just for fun.)

   It is not strictly speaking true that there is no mechanism to
   validate that you have typed in the passphrase correctly, there is
   a ``verification method''.

Yes -- what troubled me is that `cgdconfig -G' doesn't do any
verification; it doesn't even prompt twice for a pass phrase.