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

[Sven Eschenberg <sven@whgl.uni-frankfurt.de>]

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