Re: cgd questions

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sun, 1 Oct 2023 14:50:20 +0200
> From: Thomas Klausner <wiz%NetBSD.org@localhost>
> 
> I tried finding this in the man page, but it wasn't fully clear to me.
> 
> When I pick up a cgd disk and want to use it on a NetBSD system to
> which it was not connected before, what do I need?
> 
> - the passphrase
> - the /etc/cgd/foo file?

Correct.

> If you need the /etc/cgd/foo file too, how do people handle those for
> cgds used as backup disks?

Save a copy somewhere else, e.g. printed out on paper or stored in a
USB flash drive.

> The other question is that the cgd man page says that some ciphers are
> obsolete. How can I switch from an obsolete cipher to a new one - is
> the only method to make a new cgd with the new cipher and copy the
> data manually?

Correct.

Perhaps it would be worthwhile to write a utility that does the
conversion incrementally in-place.  But it at least requires some
intermediate storage on another file system to do this safely, so it's
not entirely trivial -- cgd(4) itself uses no additional writable
storage, so there's nowhere for it to record how much of the volume
has been re-encrypted or to store a write-ahead or roll-back log of
each block it is re-encrypting in case of interruption.


> Date: Sun, 01 Oct 2023 09:31:03 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> Yes, you need the /etc/cgd/foo file because the passphrase is salted,
> and you might need an iv depending on iv method.  IMHO this is a design
> bug in cgd.  At least as a normal path, one should be able to access
> with just the passphrase.

On the contrary, this was a deliberate feature of cgd(4), precisely so
that you can store the parameters file separate from the disk, e.g. on
a small USB flash drive -- and, more importantly, so that you can
plausibly destroy the parameters file and safely recycle the disk.

See the Usenix 2003 paper on cgd
https://www.usenix.org/legacy/event/usenix03/tech/freenix03/full_papers/dowdeswell/dowdeswell.pdf
for details.

This design choice also obviates the need for cgd(4) to have its own
custom writable file system format and tooling like LUKS invented just
to store the parameters (which you have to store somewhere); instead
if you really want to store it side by side with the ciphertext, you
can do so with a small ffs partition on the disk, as you described.


> Date: Tue, 03 Oct 2023 15:53:33 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> Thomas Klausner <wiz%NetBSD.org@localhost> writes:
> 
> > IIUC the cgdconfig man page correctly, this is how you do that:
> >
> >      To create a new parameters file that will generate the same key as an old
> >      parameters file:
> >
> >              # cgdconfig -G -o newparamsfile oldparamsfile
> >              old file's passphrase:
> >              new file's passphrase:
> 
> I think what that does is encrypt the old key using the new passphrase,
> and store that encrypted key in the config file.  Thus you haven't
> changed the key, but you have a config file that allows decryption with
> a new passphrase.  That's good to give a second person access, but it
> doesn't revoke the first passphrase's access, if I understood correctly.

This revokes the first password's access if you also erase
oldparamsfile.

After all, the main value of cgd(4) -- aside from protecting from
theft of your disk while your laptop is turned off -- is that if you
can erase a short parameters file, that's enough to confidently erase
the disk before recycling it without having to worry about leaking
data through sector reassignment or wear-levelling or anything.

Note: The cgd parameters file does not contain the cgd(4) disk
encryption key -- not even an encrypted key.  It doesn't even contain
enough information to confirm a guess about the password.

So if you lose a USB flash drive with the parameters file, but you
don't lose the disk itself, it is useless to an adversary on its own
to guess your password.

(What it contains -- for password-based parameters -- is a random salt
that must be combined with the password to derive the disk encryption
key.)


> Date: Mon, 2 Oct 2023 09:46:10 +0200
> From: Thomas Klausner <wiz%NetBSD.org@localhost>
> 
> I have a USB Disk with ffs-on-cgd.  I unmounted the ffs but forgot
> unconfiguring the cgd before unplugging the disk.
> 
> Can this cause problems? What kinds?

It is unlikely to lead to any sort of data loss, because if you've
unmounted ffs, then it has closed the block device and thereby
synchronously flushed all pending writes.

If attempts to read from it or write to it fail in any way other than
returning EIO (e.g., crashing the system), or if you're unable to
unconfigure it with `cgdconfig -u', please file a PR and I'll take a
look.

cgd(4) _should_ handle this scenario gracefully.  But I say that
normatively or aspirationally rather than informatively of the status
quo.  We should find a way to automatically test this scenario too,
which I'm sure we don't right now.