On Mon, Mar 14, 2016 at 09:31:36PM +0100, Milan Broz wrote: > 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.) Ok, thanks for clarifying that. > 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. Yep, none of this is a problem - it is just query that some qemu reviewers raised about impl vs spec, since neither the 4k alignment nor 1MB alignment is mentioned in the spec. > > 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. No, what I meant was that if you use AES-128 for payload encryption, but have a SHA256 hash with ESSIV, then you'll need to use AES-256 in the ESSIV calculate, not AES-128, since dm-crypt picks keysize based on the hash digest size, rather than using the same keysize as the payload. Again not a bug, just an implementation choice by dm-crypt for ESSIV. > > 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.) [snip] > If you have some patches, create issue on gitlab or github, send it to me or to the list, > whatever fits better. Thanks, will look at doing that in future. 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
