Hi Daniel, Am 14.03.2016 um 16:21 schrieb Daniel P. Berrange:
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.
Yes, that is what the 10 year old on disk specification suggests. It does even explain why this list is used/present. LUKS is not necessarily limited to the dm-crypt kernel ciphers and modes but can possibly use any crypto engine (which possibly has different naming schemes).
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.
Indeed, even though 10 years passed, all that is supported by the current LUKS implementation (cryptsetup) is what is supported by kernel's dmcrypt. You could say it became 'best practise' to use kernel's naming scheme and all it's supported ciphers. However, if a different crypto engine (I.E. a HW device) is used, there's no guarantee any of these ciphers/modes work. Personally I'd consider app. B a list of absolut minimum requirements for every crypto engine, while the user should be aware that with EVERY cipher+mode not listed, he/she is up to his/her own devices when moving to a different crypto engine.
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 ?
That is a good question. Personally I'd say a more thorough list could be added to a v2 on disk format. For v1 assuming that all ciphers and modes from the kernel are supported seems a bad idea. Just imagine that some rather obscure cipher shows up and disappears at a later time - What is the canocical list then? And the list of ciphers/modes on older kernels is way smaller aswell.
On a sidenote: When cryptsetup switched it's defaults to aes-xts it stopped being compliant to the (original) LUKS specs. No doubt.
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.
Again cryptsetup gave up on the specs, as there was a severe need for these changes. It really had been wise to ditch the original on disk format at that time and create a new revised (sub)version of the on disk format. It did not happen though and currently the reference implementation is the 'de facto' specification, while the original spec is only the 'de jure' specification. But then again, 'industry' and 'practice' define standards, don't they? *SCNR*
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 ?
While the original on disk spec was certainly typeset in LaTeX, I am not sure if Clemens ever released the source to the public and if Milan actually created the 'updated' PDF from the source. He should know though.
Regards, Daniel
Regards -Sven _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
