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 :|