Re: cgd(4) ciphers

Le 02/10/13 19:18, Roland C. Dowdeswell a écrit :
> 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.

True.

> 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.

Heh, I missed that one. Thanks for pointing it out :o

> (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?  ;-)

Of course. The usual setup for full disk encryption is rather a small 
bootloader and kernel on which we only have integrity checks (through 
TPM Seal/Unseal), and if the check is successful, unlock key.

It is by no mean easy to achieve correctly and easily though (TPM 
management + next-to-full-disk-encryption).

> 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.

Noted.

-- 
Jean-Yves Migeon