Hi Dan, On 03/14/2016 04:21 PM, Daniel P. Berrange wrote: > 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. No, it should not imply that. These modes are modes that makes sense to use. (In the time this was written these were the only usable modes. So the wording is not the best probably there.) Cryptsetup (upstream) always use "secure" defaults (from this list) but will not limit user to use anything else (even if not secure). (If you implement your block cipher or mode in kernel, cryptsetup will allow you you use it and it is not against the specs.) > 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. Yes. > 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 ? It is not restricted, specs just defines the-best use list. The whole logic is that cryptsetup will never stop you to use "insecure", combination if it is technically possible. There can be reasons to use it (a lot of old systems are not secure - but we want to map/use them with cryptsetup). > 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. IIRC LUKS header was always primary source of keyslot offset, from the first release of cryptsetup I have ever seen (btw historic versions are in archive on kernel.org). What exact algorithm in spec you mean (Figure 3? it is about LUKS format, not unlocking.) Application should not compute offsets, just it should do some sanity checks. (Unfortunately LUKS1 does not have any checksum to check that header is randomly corrupted, this will be hopefully fixed in new format - but you have to expect even intentionally malformed input anyway.) Alignment to 4k is enforced, alignment to 1MB was changed later (and used can change it) because of storage industry uses this as safe default (it is safe alignment in almost all storage stacks including SSD, RAID chunks etc - the same applies for fdisk MBR, GPT etc) I do not see problem here - it is payLoadeOffset in header. > 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. Not sure if I understand - the key for ESSIV is hash of encryption key, if you mean that, then yes. I think ESSIV was not meant to be part of LUKS spec, but there was need to develop safe IV for CBC mode. All available / supported IVs in dmcrypt are here: https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt (I should add more formal description, I have it somewhere already.) > 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 ? It's hidden in layers of dust ;-) Just joking, current version with BibTeX sources is here (just it is in wiki git): https://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-format.tex https://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-format.bib Output document (linked from homepage) is there as well https://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-format.pdf If you have some patches, create issue on gitlab or github, send it to me or to the list, whatever fits better. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
