[dm-crypt] Some questions/clarifications around the LUKS spec

Daniel P. Berrange berrange at redhat.com
Mon Mar 14 16:21:30 CET 2016

I'm working on a QEMU native implementation of the LUKS specification
and in review of that, some questions came up about the LUKS spec.

Firstly in Appendix B of the LUKS on disk specification, there are
tables which list the valid cipher names, cipher modes and hash specs.
Although not explicitly said, it appears to imply that a compliant
implementation should not allow other unspecified cipher names/modes or
hashes to be used.

Looking at the dm-crypt kernel module and cryptsetup tools though, it
appears that in practice the reference implementation allows any cipher
name/mode and hash that exists in the Linux kernel crypto subsystem to
be used.

Assuming that is correct, should the spec just be saying that the Linux
crypto subsystem defines the canonical list of valid cipher names/modes
& hashes and not imply that it is restricted to a smaller whitelist ?

The second clarification is around alignment of key material and payload.
The LUKS spec gives an algorithm for calculating the offsets of the key
material and payload, and then goes to say these values are only written
/ cached into the header for safety when reading, implying that apps could
just calculate them from first principles and sanity check against the header.

The current cryptsetup code though no longer follows the approach shown in
the spec, instead ensuring each key material section is aligned to 4k and
the payload starts at 1 MB. So the offsets in the header now *must* be
treated as the canonical data source and never calculated again from first
principles using the method shown in the spec. The changes in cryptsetup
make sense, so there's no real problem here - just something in the spec
that should be clarified to be less misleading IMHO.

One final thing is a non-obvious aspect of the ESSIV usage in LUKS, in
that the key size used in the ESSIV encryption, is not neccessarily the
same as the key sized used for the payload encryption. The key size used
for ESSIV is indirectly determined by the size of the hash algorithm
digest. This is probably something that ought to be called out in the
spec as its not entirely obvious at first sight.

This all triggers the last question which is where is the source for the
spec document ? From the styling it appears to be written in Latex originally
and periodically updated by various people but I don't see any source for
the PDF in git. So how/where should people submit patches for it ?

|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

More information about the dm-crypt mailing list