Re: cgd(4) ciphers

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

On Tue, Oct 01, 2013 at 12:14:17AM +0200, Jean-Yves Migeon wrote:
>

> Regarding point 'b': birthday attacks do increase with volume size,
> however you could circumvent this by having multiple partitions and
> concatenate them. Not as practical as a cipher suite that support
> multi-TiB partitions, but still doable.

Well, if we decide that we still want to use AES, one traditional
way to deal with this would be to generate multiple keys and use
them for different sections of the disk.  It doesn't have to be
manual catenation.  I am not suggesting that this is the best
option, but we should mention it for completeness.

> More than another cipher suite though, I think that cgd(4) needs a
> good overhaul. Currently I am more worried about separated /etc/cgd/
> config files (not that convenient to manipulate), and the relative
> difficulty to provide full-disk encryption.

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.

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.

(And putting my tongue firmly in my cheek, you can _only_ achieve
_full_ disk encryption if you store the paramsfile on another disk
because how else would you ensure that each and every disk block
is encrypted?  ;-)

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.

> It all boils down to what can be done: I have no idea how much time
> is needed to get a new cipher implemented within cgd(4), but the
> first step is to chose one. And that does not look very trivial to
> me.

A new cipher is trivial to add.  That said, what we should do is
wire it into the opencrypto(9) which will require a little work
which I haven't found time to do.

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