new default cipher modes

[GoogleCodeExporter]

Hi.

AFAICS, you switched the default cipher mode now to aes-xts-plain64 with 512B ? 
:)

1) The manpage still claims in some places that this was only a future possible 
default, and that aes-cbc-essiv:sha256 is the default.

2) Was the default only changed for LUKS?
It should be changed for plain devices as well... of course with a big fat 
entry in the NEWS file.

Cheers,
Chris.

Original issue reported on code.google.com by calestyo@gmail.com on 28 Jun 2013 at 6:17

[GoogleCodeExporter]

1) yes, fixed in man page now
see also
http://code.google.com/p/cryptsetup/wiki/Cryptsetup160

2) any change for plain mode means breaking compatibility (you have to use 
cipher spec always), will do this only if there is some some security problem 
with the mode.

But note it is configurable in compile-time, so distro maintainer can change it.

Original comment by gmazyl...@gmail.com on 28 Jun 2013 at 6:44

• Changed state: Fixed

[GoogleCodeExporter]

1) I have debian's 2:1.6.1-1 and there it still says e.g.
The current default in the distributed sources is "aes-cbc-essiv:sha256" for 
both plain dm-crypt and LUKS.

2) Well, but therefore we have NEWS files,... and people who depended on the 
defaults and didn't explicitly specify their modes - I guess you can't help 
such guys.

The problem now is that you get even more and more new deployments which use 
the "old" modes.

Actually, I think the best solution would be to not provide a default for 
non-LUKS at all.
Since it will always cause troubles when you sooner or later want to change the 
defaults.

Cheers,
Chris.

Original comment by calestyo@gmail.com on 28 Jun 2013 at 7:16

[GoogleCodeExporter]

1) because I changed it few minutes ago in devel git :)
http://code.google.com/p/cryptsetup/source/detail?r=8b162ca258818bd6485cfee6b5b6
429544163df3

2) it was a lot breakage when we did this in
http://code.google.com/p/cryptsetup/wiki/Cryptsetup110
(and here the reason was security issue - plain IV & possible watermark attack)
(Maybe one day default will change but for now I do not think it is really 
needed.)
LUKS is the preferred solution for long time.
Cryptsetup will always prefer backward compatible solution with the exceptions 
when  it is less secure. Not providing default means the same breakage, 
moreover, initscript and systemd now supports it directly from /etc/crypttab
(in fact, systemd has still problems with plain crypt... 
https://bugzilla.redhat.com/show_bug.cgi?id=759402 )

Original comment by gmazyl...@gmail.com on 28 Jun 2013 at 7:38

[GoogleCodeExporter]

1) Ah... by referring http://code.google.com/p/cryptsetup/wiki/Cryptsetup160 
before, I thought you'd mean that this was already fixed in 1.60 ;)

2) Well... should you ever change it... anyway (once I've broke it ;-P)... then 
remember to consider to drop the defaults for plain dm-crypt completely... 
they're like a curse in that respect ;-)

Cheers,
Chris.

Original comment by calestyo@gmail.com on 28 Jun 2013 at 8:53

[GoogleCodeExporter]

Maybe I can add some warning if plain cryptsetup create is used without cipher 
and keysize option.

But you can see it from the other POV - if anyone is using plain dmcrypt 
encrypted swap with random generated key (this is still very common), these 
people will get new mode for free after update. If the parameters are 
mandatory, they have to fix scripts to get new mode themselves...

Original comment by gmazyl...@gmail.com on 28 Jun 2013 at 9:07

[GoogleCodeExporter]

One more question:

What was the reason for using AES128 over AES256?

And the same, for staying with SHA1 as default for --hash in case of LUKS?

Original comment by calestyo@gmail.com on 28 Jun 2013 at 10:32