From: "Daniel P. Berrange" <berrange@redhat.com>
To: Milan Broz <gmazyland@gmail.com>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] Some questions/clarifications around the LUKS spec
Date: Tue, 15 Mar 2016 10:23:06 +0000 [thread overview]
Message-ID: <20160315102306.GB3168@redhat.com> (raw)
In-Reply-To: <56E71FA8.2020503@gmail.com>
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 :|
prev parent reply other threads:[~2016-03-15 10:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-14 15:21 [dm-crypt] Some questions/clarifications around the LUKS spec Daniel P. Berrange
2016-03-14 18:58 ` Sven Eschenberg
2016-03-14 19:54 ` Milan Broz
2016-03-14 21:24 ` Sven Eschenberg
2016-03-14 22:27 ` Milan Broz
2016-03-15 14:21 ` Sven Eschenberg
2016-04-27 12:56 ` [dm-crypt] Cryptesetup and dm-crypt levent demir
2016-04-27 16:35 ` Arno Wagner
2016-03-14 20:31 ` [dm-crypt] Some questions/clarifications around the LUKS spec Milan Broz
2016-03-15 10:23 ` Daniel P. Berrange [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160315102306.GB3168@redhat.com \
--to=berrange@redhat.com \
--cc=dm-crypt@saout.de \
--cc=gmazyland@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox