From: Milan Broz <mbroz@redhat.com>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT
Date: Wed, 18 Nov 2009 12:20:05 +0100 [thread overview]
Message-ID: <4B03D865.8070905@redhat.com> (raw)
In-Reply-To: <20091118102515.GB30910@tansi.org>
On 11/18/2009 11:25 AM, Arno Wagner wrote:
> I am not sure this really is a security issue. It may confuse users,
> but they will still be secure. Most probably use defaults anyways.
Or distro installation defaults.. e.g. Fedora12 installer switched
to AES in XTS mode (with 512bit - so it uses AES-256)...
> But if we change this, I propose to make aes-cbc-essiv:sha256
> the default for plain dm-crypt and to increase LUKS key length
> to 256 bits as well. The performance loss is apparently very
> small (10% or so).
I thought about default change for LUKS in cryptsetup 1.1.0, but...
For default LUKS cipher:
I agree with switching default to 256bits for LUKS)
(aes-cbc-essiv:sha256 is already default), just some ideas
- some discussions about recent theoretic attacks against AES-256
(related key), maybe some people want use AES-128...
- for recent kernel, XTS mode is more appropriate, but it cause
backward incompatibility (XTS is not available in old kernels)
(IOW default to aes-xts-plain ?)
(Ignoring the 32-only plain IV problem here, because XTS suggested use
is for volumes <1TB. I have already patch for plain64 dm-crypt IV btw,
just it got lost in Alasdair's upstream patch queue.)
For default LUKS header hash:
- default is SHA1
switching to another (probably SHA-256?) means complete incompatibility
with all cryptsetup <1.1.x, this need some time when all most distros
use new cryptsetup.
No need to hurry, there is no problem with SHA1 in this application
of hash function.
For plain cipher mode:
I am not sure if it is good idea to change default, if anyone using
default in crypttab, it cause serious incompatibility with possible data loss.
But I agree that aes-cbc-essiv:sha256 is better default here.
Can distro maintainers think about this? There is not problem
for encryption of swap using random key.
Maybe it will need some warning during upgrade if there is such plain
volume in crypttab.
Please correct me if I am wrong:-)
So, if there are no objections, I'll change default key size for LUKS to 256bits
in final cryptsetup 1.1.0 release. The plain default is still open question.
Milan
--
mbroz@redhat.com
next prev parent reply other threads:[~2009-11-18 11:20 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-17 22:45 [dm-crypt] different default key sizes for CREATE and LUKSFORMAT Stefan Xenon
2009-11-18 5:45 ` Arno Wagner
2009-11-18 10:01 ` Stefan Xenon
2009-11-18 10:25 ` Arno Wagner
2009-11-18 11:20 ` Milan Broz [this message]
2009-11-18 13:26 ` Milan Broz
2009-11-18 15:17 ` Heinz Diehl
2009-11-19 7:41 ` Arno Wagner
2009-11-19 9:21 ` Heinz Diehl
2009-11-19 12:24 ` Arno Wagner
2009-11-19 12:28 ` Arno Wagner
2009-11-19 13:00 ` Heinz Diehl
2009-11-20 12:14 ` Milan Broz
2009-11-20 15:43 ` Heinz Diehl
2009-11-21 10:47 ` Arno Wagner
2009-11-21 12:40 ` Stefan Xenon
2009-11-21 17:26 ` Arno Wagner
2009-11-19 20:00 ` Stefan Xenon
2009-11-20 12:22 ` Milan Broz
2009-11-23 13:45 ` Roscoe
2009-11-23 14:29 ` Milan Broz
2009-11-23 15:46 ` Arno Wagner
2009-11-23 16:05 ` Heinz Diehl
2009-11-19 7:28 ` Arno Wagner
2009-11-20 12:43 ` Jonas Meurer
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=4B03D865.8070905@redhat.com \
--to=mbroz@redhat.com \
--cc=dm-crypt@saout.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.