Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Jean-Yves Migeon (jeanyves.migeonfree.fr)
Date: Wed Oct 02 2013 - 14:06:26 CDT
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.
> 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
>> 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
> 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.