On 01.01.2017 23:23, Milan Broz wrote:
> On 12/30/2016 07:31 AM, Carl-Daniel Hailfinger wrote:
>> Followup to myself:
>>
>> A patch for cryptsetup follows. It does not talk to the kernel interface
>> yet, but it can decode v7 of the GELI header.
>> Keyfile support is next to decrypt the encrypted metadata in the header.
> I think we can implement it as just another supported on-disk format but
> it will need some testing images and full integration in libcryptsetup
> (similar to TrueCrypt/VeraCrypt formats).

I'm using the TrueCrypt/VeraCrypt code in libcryptsetup as template for
the GELI code.


> I can do that myself but I would like to have full documentation and/or
> implementation of parsing of GELI on-disk format.

That's actually a problem. The available documentation about the on-disk
format is essentially just the FreeBSD code, and various bits and pieces
scattered all over the net.

GELI code in FreeBSD:
https://svnweb.freebsd.org/base/head/sys/geom/eli/

Example GPLv3 code in GRUB (for password-based containers only):
http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/disk/geli.c
http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/disk/cryptodisk.c

Example GPLv3 code as a NBD implementation:
https://github.com/jepler/ungeli

Bits and pieces of documentation (not all of them refer to the current
version of GELI):
https://www.freebsd.org/cgi/man.cgi?geli(8)
https://www.freebsd.org/doc/handbook/disks-encrypting.html
https://lists.freebsd.org/pipermail/freebsd-geom/2012-June/005284.html
http://www.derkeiler.com/Newsgroups/sci.crypt/2005-07/0959.html

The way keys are generated, stored and used is not entirely
straightforward. The various pieces of documentation and analysis
contradict each other and I have not verified which one is correct, so
please take this with a large heap of salt, it might be totally bogus:
For some cases, a 64-byte key file (generated from random data) is
hashed with SHA512, the last 256 bits of the hash are thrown away, and
the remaining 256 bits are divided into an IV key and an AES-128 key.
For older versions of GELI, the IV key is used for AES encryption as
well (a bug which was corrected in newer versions of GELI). The metadata
has two key store slots. Each slot hosts an encrypted version of the
master key (which itself is divided into IV key and encryption "data"
key) and the SHA512 hash of the master key. The "data" key part of the
master key is not directly used for AES-XTS encryption, but there are
more derivation mechanisms in there which are relevant for storage media
larger than 2^20 blocks.

A quick note about the on-disk format: Ciphertext starts directly at the
beginning of the container. The metadata is stored in the last 512-byte
sector of the container. Soft sectors are usually 4096 bytes, optionally
amended with a 512-byte authentication data sector per 4096-byte soft
sector. AFAIK no third-party code supports authentication data.


> And it will take some time (maybe create issue for it in project tracker).

I noticed that I had forgotten to attach the current state of the
implementation. I think patch 3 compiles and does something useful,
patch 4 is the current state (and probably doesn't compile). The code is
full of #if 0 and similar crud, and you can see it's just messing with
the TCRYPT code to replace some of the code with GELI code. The code
does NOT reflect my coding standards, it's just a crufty hack while I
was figuring out how to add code to cryptsetup.

What the code does right now is parse a container and output the
encrypted keyslots as well as check the MD5 checksum of the metadata.


> Anyway, thanks for working on this!

You're welcome. I hope to revisit this in a few weeks when I have more time.

Regards,
Carl-Daniel