Re: [patch] cgd

["Roland C. Dowdeswell" <elric%imrryr.org@localhost>]

On Sat, Nov 27, 2010 at 02:40:11AM +0000, Taylor R Campbell wrote:
>

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.

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 am not subscribed to this list, so please cc me in replies.)
> 
> I tried to use cgd yesterday, and was pretty by the man pages and the
> use of cgdconfig; I also stumbled across some bugs in cgdconfig.  I am
> not a cryptographer, and thus am unqualified to give cryptographic
> advice, but I thought it might be worthwhile for the man pages to be a
> little clearer on the disk format -- enough to write programs that
> read and write it -- and to mention some cryptographic limitations of
> cgd.
> 
> Attached is a patch to HEAD that fixes some errors in the
> implementation and documentation.  However, I eventually gave up on
> trying to use cgdconfig[*], so I wrote my own trivial utilities (at
> <http://mumble.net/~campbell/tmp/cgdutil-20101127.tgz> for the time
> being, for anyone curious) to serve its function, when combined with
> external tools such as scrypt <http://www.tarsnap.com/scrypt/>.
> 
> Comments?  I would submit a PR for the patch, but, as I said, I am not
> a cryptographer, so I am interested more in review on the patch (and
> corrections to my misconceptions about cgd, if any) than just in
> applying the patch.
> 
> [*] Aside from having a usage model that confused me, cgdconfig lacks
>     any cryptographic integrity checks -- a passphrased parameters
>     file is not actually bound to a particular key, so, for instance,
>     if you `cgdconfig -G' up a new parameters file, mistype a
>     passphrase, and delete the old one, cgdconfig won't (can't!)
>     notice, and your cgd will be lost and gone forever.  In contrast,
>     an scrypt file is cryptographically bound to its contents, so
>     scrypt can say whether you typed the correct passphrase or not.

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.

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''.  This will configure the disk and verify
that it can find there what you instruct it to find which effectively
validates the passphrase.  The verification mechanism approach that
I implement in the params file can be configured to check if the
a passphrase yields a device which has either a valid disklabel or
is in and of itself an FFS partition which is sufficient proof that
the passphrase is correct and does not suffer the disadvantage of
providing another easier verification mechanism to a malicious user
than already would necessarily exist.

This is also the reason that I chose to implement the params file
as a plain file rather than a few magic bytes at the beginning of
the volume, that is to allow the file to place in an arbitrary
location outside of the actual volume to enhance security in many
scenarios.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/