Re: Problem with cgdconfig

[Jan Danielsson <jan.m.danielsson%gmail.com@localhost>]

On 11/04/15 14:42, Greg Troxel wrote:
[---]
> Sort of related, I am a bit confused about how cgd is supposed to work.
> I understand that one has a config file in /etc/cgd with IV and password
> method, but that's in the root of one system, and doesn't naturally
> travel with external disks.  Particularly if the external disk contains
> a full backup, one wants to read it without the original system.

   Keeping the parameter and the encrypted file separate is by design,
so how the parameter file travels along with the disk is up to the user
to decide; cgd has no part in that.  There was a short discussion a long
time back about storing the cgd parameters on disk (next to the
encrypted data), but I think that's a bad idea -- or rather, I think
it's okay if it would be an optional feature and is implemented in a way
so that it doesn't affect the current implementation (which would be
problematic).

   Ignoring the problem with "stored key" parameter files, one problem
with storing the cgd parameter data on-disk is that we would need to
find a place to store it.

   When cgd first appeared in NetBSD I toyed around with placing
parameter files on disk by simply dd:ing them (padded) to unused sectors
before the cgd-partition.  This has plenty of problems, but for my
highly controlled environment it worked fine.  (I wrote a minimal
wrapper around cgdconfig which fetched the parameter files before
attempting to configure a cgd device).

   Captain Obvious(tm) notes: Using "unused" space is a bad idea because
others may have the same idea, and also that "unused" space may no
longer be unused in other/future versions of the operating system.

   Moving the encrypted cgd data to an offset in order to fit a header
(for the parameters) doesn't feel good.  Not only because it would break
compatibility with current cgd drives/partitions, but also because I
like the idea of knowing that there's no magic in the partition, it's
elegant; apart from the encryption it behaves just like any other
drives/partition -- all the offsets/sizes are just as they would be
without cgd.

  Also the cgd parameter format is extensible in a way which isn't
trivially translatable to a raw on-disk "header" format.

> So should I be created two filesystems on each disk, one very small, to
> hold a cgdconfig file, and one large, encrypted?   Or is there some
> other approach?   Are there some standard flags that one should just
> remember and use, so you don't need a config file?

   Using two partitions is a straight-forward solution.

   If you want to be able to recreate the parameter file from scratch,
and depending on how strict your security requirements are; it's
probably easiest to memorize a passphrase, hash that passphrase, and use
the result as a cgd storedkey.  (cgdconfig -s may be relevant, though I
have never used it myself).

   Perhaps the shell_out key generation method can be helpful.

   If you are uncomfortable using storedkey, then use PKCS#5
PBKDF2/SHA1; memorize the number of "iterations", and then generate the
salt in a deterministic way (hash a strong passphrase, for instance).
The rest of the parameters should be easy to memorize.   (And when
someone asks you what crazy person told you to derive the salt like
that, please omit my name.  As long as no one reads this mail (.. on a
public mailing list ..) and everyone thinks your salt is random, you'll
be fine :).


   Personally I keep a copy of some of my cgd parameters files on my
phone (encrypted (by other means than cgd obviously)).  This is not only
for portability, but also serves as an extra backup of the parameter files.


-- 
Kind Regards,
Jan