On 05.01.2017 09:53, Carl-Daniel Hailfinger wrote: > 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. Please note that SHA512 is always used as HMAC-SHA512 with zero key. > 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
