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 ? Regards, Daniel -- |: 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 :| _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
