[dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Milan Broz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The stable cryptsetup 1.6.4 release is available at

    https://code.google.com/p/cryptsetup/

Please note that release packages are now located on kernel.org

    https://www.kernel.org/pub/linux/utils/cryptsetup/v1.6/

Feedback and bug reports are welcomed.

Cryptsetup 1.6.4 Release Notes
==============================

Changes since version 1.6.3

* Implement new erase (with alias luksErase) command.

  The erase cryptsetup command can be used to permanently erase
  all keyslots and make the LUKS container inaccessible.
  (The only way to unlock such device is to use LUKS header backup
  created before erase command was used.)

  You do not need to provide any password for this operation.

  This operation is irreversible.

* Add internal "whirlpool_gcryptbug hash" for accessing flawed
  Whirlpool hash in gcrypt (requires gcrypt 1.6.1 or above).

  The gcrypt version of Whirlpool hash algorithm was flawed in some
  situations.

  This means that if you used Whirlpool in LUKS header and upgraded
  to new gcrypt library your LUKS container become inaccessible.

  Please refer to cryptsetup FAQ for detail how to fix this situation.

* Allow to use --disable-gcrypt-pbkdf2 during configuration
  to force use internal PBKDF2 code.

* Require gcrypt 1.6.1 for imported implementation of PBKDF2
  (PBKDF2 in gcrypt 1.6.0 is too slow).

* Add --keep-key to cryptsetup-reencrypt.

  This allows change of LUKS header hash (and iteration count) without
  the need to reencrypt the whole data area.
  (Reencryption of LUKS header only without master key change.)

* By default verify new passphrase in luksChangeKey and luksAddKey
  commands (if input is from terminal).

* Fix memory leak in Nettle crypto backend.

* Support --tries option even for TCRYPT devices in cryptsetup.

* Support --allow-discards option even for TCRYPT devices.
  (Note that this could destroy hidden volume and it is not suggested
   by original TrueCrypt security model.)

* Link against -lrt for clock_gettime to fix undefined reference
  to clock_gettime error (introduced in 1.6.2).

* Fix misleading error message when some algorithms are not available.

* Count system time in PBKDF2 benchmark if kernel returns no self usage info.
  (Workaround to broken getrusage() syscall with some hypervisors.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJTD04wAAoJENmwV3vZPpj8M7oQAMbDHAyN6LezVcIUgbfDJXP6
eqAP6uxjI3Z0gu0+ibui5LfmCHinSaFvNoBrdc/QORjMWwUJdZ4LWu5YCiUdbs4x
434ovIGrMVf3m4fe9ZoJAUgTvYWYt4iPv4vtyTYfO9N/MjMDdJAcrdYWm2Aw0Azx
ElD9EnOywPUNNCrKF4fuNH24GBuYh/6vHmoPGwE+R+zZQlRo68AsxZuc0ESqY2eO
GHJ39uQOl8UzxcspJwBalDo2PM9fvVMffJdnMc9E9m28JqmoSVLKLq+y1dPFn0e3
fecWiDvSDGfzPIpDZZcQOnDDfnah/HyX5tpijbGvGqzEgHh9AwBq2oSxrQj28yYe
bj5Qo2fHEQ1hR/Klb20a5cHLlhX3c86/P6RHVsf7Hq9Dzd5U009s659ZX3RIqnfk
oi1tjwrHKpkTqgF5/Ww8fuujvNCwATW+cJ5twgN1bYei7vK8H3eYcmSrp+OXa0Tc
tFFgFKG5XkUNBOoFhCLXTJvByco+O9l3NY5rJa3Zlq+jcH5ryhB69TZW+LkicYsc
nX9LEIPxeX+eaaM/hP/t25aRQFm7/Oy/lib7l8m55FYXmBTjvhbOInjkApc/NCGw
aAG5hdA75lAl+HYdaE0rHe9iOH3D2ZRCm667UjFPHLWxBVzOd/vMNwo0K0Zls/ps
Aphn84K2ZuPizxFBf9hx
=UIgE
-----END PGP SIGNATURE-----

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Thomas Bächler]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

Am 27.02.2014 15:39, schrieb Milan Broz:
> The stable cryptsetup 1.6.4 release is available at
> 
>     https://code.google.com/p/cryptsetup/
> 
> Please note that release packages are now located on kernel.org
> 
>     https://www.kernel.org/pub/linux/utils/cryptsetup/v1.6/
> 
> Feedback and bug reports are welcomed.

Thank you for your work on cryptsetup.

> * Add internal "whirlpool_gcryptbug hash" for accessing flawed
>   Whirlpool hash in gcrypt (requires gcrypt 1.6.1 or above).
> 
>   The gcrypt version of Whirlpool hash algorithm was flawed in some
>   situations.
> 
>   This means that if you used Whirlpool in LUKS header and upgraded
>   to new gcrypt library your LUKS container become inaccessible.
> 
>   Please refer to cryptsetup FAQ for detail how to fix this situation.

I don't see any information on how to fix this problem in the FAQ. Can
you provide a more precise reference?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Heinz Diehl]

On 27.02.2014, Milan Broz wrote: 

> * Add internal "whirlpool_gcryptbug hash" for accessing flawed
>   Whirlpool hash in gcrypt (requires gcrypt 1.6.1 or above).
> 
>   The gcrypt version of Whirlpool hash algorithm was flawed in some
>   situations.

Just to be shure: if I create an encrypted partition using 
the whirlpool hash algorithm with recent cryptsetup / libgcrypt, 
does it have its full strength?

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Arno Wagner]

On Thu, Feb 27, 2014 at 22:44:53 CET, Heinz Diehl wrote:
> On 27.02.2014, Milan Broz wrote: 
> 
> > * Add internal "whirlpool_gcryptbug hash" for accessing flawed
> >   Whirlpool hash in gcrypt (requires gcrypt 1.6.1 or above).
> > 
> >   The gcrypt version of Whirlpool hash algorithm was flawed in some
> >   situations.
> 
> Just to be shure: if I create an encrypted partition using 
> the whirlpool hash algorithm with recent cryptsetup / libgcrypt, 
> does it have its full strength?

As far as I understand this, yes. The old version in libgcrypt
was flawed, the repair hence breaks old headers created with it.
The caveat in FAQ item 8.3 does still applies though.

Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Milan Broz]

On 02/27/2014 06:30 PM, Thomas Bächler wrote:
>>   This means that if you used Whirlpool in LUKS header and upgraded
>>   to new gcrypt library your LUKS container become inaccessible.
>>
>>   Please refer to cryptsetup FAQ for detail how to fix this situation.
> 
> I don't see any information on how to fix this problem in the FAQ. Can
> you provide a more precise reference?

Yes, sorry, this is one item I simply had no time to finish.

Gimme few hours, I will reply later with exact description once I get to it.

Thanks,
Milan

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Milan Broz]

On 02/27/2014 06:30 PM, Thomas Bächler wrote:
> Am 27.02.2014 15:39, schrieb Milan Broz:
>> The stable cryptsetup 1.6.4 release is available at
>>
>>     https://code.google.com/p/cryptsetup/
>>
>> Please note that release packages are now located on kernel.org
>>
>>     https://www.kernel.org/pub/linux/utils/cryptsetup/v1.6/
>>
>> Feedback and bug reports are welcomed.
> 
> Thank you for your work on cryptsetup.
> 
>> * Add internal "whirlpool_gcryptbug hash" for accessing flawed
>>   Whirlpool hash in gcrypt (requires gcrypt 1.6.1 or above).
>>
>>   The gcrypt version of Whirlpool hash algorithm was flawed in some
>>   situations.
>>
>>   This means that if you used Whirlpool in LUKS header and upgraded
>>   to new gcrypt library your LUKS container become inaccessible.
>>
>>   Please refer to cryptsetup FAQ for detail how to fix this situation.
> 
> I don't see any information on how to fix this problem in the FAQ. Can
> you provide a more precise reference?

These are the steps for fixing Whirlpool gcrypt issue, there is manual hack
to LUKS header required, otherwise it is straightforward. I think this
should be in FAQ as well...

(Feel free to fix this description, I just quickly tested this on Arch distro.
Probably more safe script can be written, volunteers welcome ;-)

How to fix "flawed gcrypt Whirlpool" hash in LUKS header

All the text below expects cryptsetup 1.6.4 installed.
(Previous version doesn't have needed code for workaround.)

What's the problem?

- gcrypt in version prior to 1.6.0 includes flawed Whirlpool hash
(bug only hits when hash is calculated in multiple chunks, unfortunately
this is the cryptsetup case).
If you use Whirlpool as LUKS header hash with previous gcrypt and upgrade
to gcrypt 1.6.x, you cannot open LUKS device anymore.

These are the steps how to fix it in-place:

-1) Backup LUKS header. Really. (see luksHeaderBackup command)

0) Use cryptsetup 1.6.4 or more recent.


1) double check which gcrypt you are using. You can even use cryptsetup here:

  # cryptsetup luksDump <your luks device> --debug | grep backend

  - for flawed (old gcrypt) you should see something like this:
  # Crypto backend (gcrypt 1.5.3, flawed whirlpool) initialized.

  - for already fixed gcrypt you should see
  # Crypto backend (gcrypt 1.6.1) initialized.


Next step depends if you can unlock the device (old gcrypt) or you
are already running upgraded system (and cannot unlock LUKS device anymore).


2a) If you can unlock device (you have still old gcrypt and want to prepare
for gcrypt upgrade) simply reencrypt LUKS header with different hash (e.g. sha256)

  # cryptsetup-reencrypt --keep-key --hash sha256 <your luks device>

and you are done (you will need to enter all keyslot passphrasses).


2b) If you have already broken system (upgraded gcrypt).

  - you MUST use gcrypt 1.6.1 or more recent
  (requires bug emulation flag, cryptsetup must be compiled with this version)

  - now you need to change LUKS header hash name from "whirlpool" to "whirlpool_gcryptbug"
  (this requires manual overwrite). You can use hex editor or e.g.

   # echo -n -e 'whirlpool_gcryptbug\0' | dd of=<luks device> bs=1 seek=72 conv=notrunc

   verify with cryptsetup luksDump. This step is dangerous, so be sure you have backups
   (notrunc dd option it very important for LUKS images in file).

  And now you can open the device again.

  I strongly suggest to change LUKS hash now as described in 2a) so your device
  is compatible with older distros again.

Milan

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Arno Wagner]

On Fri, Feb 28, 2014 at 12:29:35 CET, Milan Broz wrote:
[...]
> These are the steps for fixing Whirlpool gcrypt issue, there is manual hack
> to LUKS header required, otherwise it is straightforward. I think this
> should be in FAQ as well...

I will add it.

Arno

> (Feel free to fix this description, I just quickly tested this on Arch distro.
> Probably more safe script can be written, volunteers welcome ;-)
> 
> How to fix "flawed gcrypt Whirlpool" hash in LUKS header
> 
> All the text below expects cryptsetup 1.6.4 installed.
> (Previous version doesn't have needed code for workaround.)
> 
> What's the problem?
> 
> - gcrypt in version prior to 1.6.0 includes flawed Whirlpool hash
> (bug only hits when hash is calculated in multiple chunks, unfortunately
> this is the cryptsetup case).
> If you use Whirlpool as LUKS header hash with previous gcrypt and upgrade
> to gcrypt 1.6.x, you cannot open LUKS device anymore.
> 
> These are the steps how to fix it in-place:
> 
> -1) Backup LUKS header. Really. (see luksHeaderBackup command)
> 
> 0) Use cryptsetup 1.6.4 or more recent.
> 
> 
> 1) double check which gcrypt you are using. You can even use cryptsetup here:
> 
>   # cryptsetup luksDump <your luks device> --debug | grep backend
> 
>   - for flawed (old gcrypt) you should see something like this:
>   # Crypto backend (gcrypt 1.5.3, flawed whirlpool) initialized.
> 
>   - for already fixed gcrypt you should see
>   # Crypto backend (gcrypt 1.6.1) initialized.
> 
> 
> Next step depends if you can unlock the device (old gcrypt) or you
> are already running upgraded system (and cannot unlock LUKS device anymore).
> 
> 
> 2a) If you can unlock device (you have still old gcrypt and want to prepare
> for gcrypt upgrade) simply reencrypt LUKS header with different hash (e.g. sha256)
> 
>   # cryptsetup-reencrypt --keep-key --hash sha256 <your luks device>
> 
> and you are done (you will need to enter all keyslot passphrasses).
> 
> 
> 2b) If you have already broken system (upgraded gcrypt).
> 
>   - you MUST use gcrypt 1.6.1 or more recent
>   (requires bug emulation flag, cryptsetup must be compiled with this version)
> 
>   - now you need to change LUKS header hash name from "whirlpool" to "whirlpool_gcryptbug"
>   (this requires manual overwrite). You can use hex editor or e.g.
> 
>    # echo -n -e 'whirlpool_gcryptbug\0' | dd of=<luks device> bs=1 seek=72 conv=notrunc
> 
>    verify with cryptsetup luksDump. This step is dangerous, so be sure you have backups
>    (notrunc dd option it very important for LUKS images in file).
> 
>   And now you can open the device again.
> 
>   I strongly suggest to change LUKS hash now as described in 2a) so your device
>   is compatible with older distros again.
> 
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Sven Eschenberg]

Just out of curiosity,

Isn't it possible (yet) to override header fields during luksopen? If not,
wouldn't it make sense to add something like that in future versions? I
think it could be of great help when the header is partly damaged, to be
able to override things without using a hex editor.

I am aware that one could use the non-LUKS mode to open a LUKS device by
passing all required parameters, admitted. But a mode where one can use
what's in the header and override single fields could be interesting. Once
the correct params are determinde this way, one could maybe add an option
to repair the header with the given replacements (Maybe by adding the
option to reencryt?).

Just some thoughts that crossed my mind.

Regards

-Sven


On Fri, February 28, 2014 12:29, Milan Broz wrote:
> On 02/27/2014 06:30 PM, Thomas Bächler wrote:
>> Am 27.02.2014 15:39, schrieb Milan Broz:
>>> The stable cryptsetup 1.6.4 release is available at
>>>
>>>     https://code.google.com/p/cryptsetup/
>>>
>>> Please note that release packages are now located on kernel.org
>>>
>>>     https://www.kernel.org/pub/linux/utils/cryptsetup/v1.6/
>>>
>>> Feedback and bug reports are welcomed.
>>
>> Thank you for your work on cryptsetup.
>>
>>> * Add internal "whirlpool_gcryptbug hash" for accessing flawed
>>>   Whirlpool hash in gcrypt (requires gcrypt 1.6.1 or above).
>>>
>>>   The gcrypt version of Whirlpool hash algorithm was flawed in some
>>>   situations.
>>>
>>>   This means that if you used Whirlpool in LUKS header and upgraded
>>>   to new gcrypt library your LUKS container become inaccessible.
>>>
>>>   Please refer to cryptsetup FAQ for detail how to fix this situation.
>>
>> I don't see any information on how to fix this problem in the FAQ. Can
>> you provide a more precise reference?
>
> These are the steps for fixing Whirlpool gcrypt issue, there is manual
> hack
> to LUKS header required, otherwise it is straightforward. I think this
> should be in FAQ as well...
>
> (Feel free to fix this description, I just quickly tested this on Arch
> distro.
> Probably more safe script can be written, volunteers welcome ;-)
>
> How to fix "flawed gcrypt Whirlpool" hash in LUKS header
>
> All the text below expects cryptsetup 1.6.4 installed.
> (Previous version doesn't have needed code for workaround.)
>
> What's the problem?
>
> - gcrypt in version prior to 1.6.0 includes flawed Whirlpool hash
> (bug only hits when hash is calculated in multiple chunks, unfortunately
> this is the cryptsetup case).
> If you use Whirlpool as LUKS header hash with previous gcrypt and upgrade
> to gcrypt 1.6.x, you cannot open LUKS device anymore.
>
> These are the steps how to fix it in-place:
>
> -1) Backup LUKS header. Really. (see luksHeaderBackup command)
>
> 0) Use cryptsetup 1.6.4 or more recent.
>
>
> 1) double check which gcrypt you are using. You can even use cryptsetup
> here:
>
>   # cryptsetup luksDump <your luks device> --debug | grep backend
>
>   - for flawed (old gcrypt) you should see something like this:
>   # Crypto backend (gcrypt 1.5.3, flawed whirlpool) initialized.
>
>   - for already fixed gcrypt you should see
>   # Crypto backend (gcrypt 1.6.1) initialized.
>
>
> Next step depends if you can unlock the device (old gcrypt) or you
> are already running upgraded system (and cannot unlock LUKS device
> anymore).
>
>
> 2a) If you can unlock device (you have still old gcrypt and want to
> prepare
> for gcrypt upgrade) simply reencrypt LUKS header with different hash (e.g.
> sha256)
>
>   # cryptsetup-reencrypt --keep-key --hash sha256 <your luks device>
>
> and you are done (you will need to enter all keyslot passphrasses).
>
>
> 2b) If you have already broken system (upgraded gcrypt).
>
>   - you MUST use gcrypt 1.6.1 or more recent
>   (requires bug emulation flag, cryptsetup must be compiled with this
> version)
>
>   - now you need to change LUKS header hash name from "whirlpool" to
> "whirlpool_gcryptbug"
>   (this requires manual overwrite). You can use hex editor or e.g.
>
>    # echo -n -e 'whirlpool_gcryptbug\0' | dd of=<luks device> bs=1 seek=72
> conv=notrunc
>
>    verify with cryptsetup luksDump. This step is dangerous, so be sure you
> have backups
>    (notrunc dd option it very important for LUKS images in file).
>
>   And now you can open the device again.
>
>   I strongly suggest to change LUKS hash now as described in 2a) so your
> device
>   is compatible with older distros again.
>
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Arno Wagner]

On Fri, Feb 28, 2014 at 22:26:03 CET, Sven Eschenberg wrote:
> Just out of curiosity,
> 
> Isn't it possible (yet) to override header fields during luksopen? If not,
> wouldn't it make sense to add something like that in future versions? I
> think it could be of great help when the header is partly damaged, to be
> able to override things without using a hex editor.

I doubt this makes much sense. From what I have seen,
usually the magic string at the start is gone as well,
and then there is a real risk that people try this with
the wrong data. Using a hex-editor is not that hard and
using a hex-dumper is basically required to get any 
reasonable form of diagnostics. Even the keyslot-
checker is basically a specialized hexdump tool.
 
> I am aware that one could use the non-LUKS mode to open a LUKS device by
> passing all required parameters, admitted. But a mode where one can use
> what's in the header and override single fields could be interesting. Once
> the correct params are determinde this way, one could maybe add an option
> to repair the header with the given replacements (Maybe by adding the
> option to reencryt?).
> 
> Just some thoughts that crossed my mind.

I doubt this really helps. Also remember that finding out what
actually broke the header is important, so fiddeling around
with an opaque header and commandline arguments to cryptsetup
after you have analyzed a hexdump strikes me as not that effective.

I do understand that hex-editing is akward for many people, 
but I do not think this makes it any better or clearer.
One thing that would help a bit is a header layout with 
hex offsets. I think I am going to add that to the FAQ. 

Admittedly, the whirlpool problem (BTW, now documented in
FAQ Item 8.3) would be easy to solve with your proposal.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Sven Eschenberg]

On Fri, February 28, 2014 22:46, Arno Wagner wrote:
> On Fri, Feb 28, 2014 at 22:26:03 CET, Sven Eschenberg wrote:
>> Just out of curiosity,
>>
>> Isn't it possible (yet) to override header fields during luksopen? If
>> not,
>> wouldn't it make sense to add something like that in future versions? I
>> think it could be of great help when the header is partly damaged, to be
>> able to override things without using a hex editor.
>
> I doubt this makes much sense. From what I have seen,
> usually the magic string at the start is gone as well,
> and then there is a real risk that people try this with
> the wrong data. Using a hex-editor is not that hard and
> using a hex-dumper is basically required to get any
> reasonable form of diagnostics. Even the keyslot-
> checker is basically a specialized hexdump tool.

Okay, that's true. I personally do use a hexeditor too, I have to admit,
just thought it could help less experienced people. Then again, if people
fail to use a hex editor chances are big they make things worse. I guess I
didn't think this through long enough.

>
>> I am aware that one could use the non-LUKS mode to open a LUKS device by
>> passing all required parameters, admitted. But a mode where one can use
>> what's in the header and override single fields could be interesting.
>> Once
>> the correct params are determinde this way, one could maybe add an
>> option
>> to repair the header with the given replacements (Maybe by adding the
>> option to reencryt?).
>>
>> Just some thoughts that crossed my mind.
>
> I doubt this really helps. Also remember that finding out what
> actually broke the header is important, so fiddeling around
> with an opaque header and commandline arguments to cryptsetup
> after you have analyzed a hexdump strikes me as not that effective.

That's absolutely true, indeed.

>
> I do understand that hex-editing is akward for many people,
> but I do not think this makes it any better or clearer.
> One thing that would help a bit is a header layout with
> hex offsets. I think I am going to add that to the FAQ.

Good point, I'd propose adding this to the luks on disk format document as
well. If you cannot convert HEX<->DEC inside your head having the hex
offsets at disposal helps alot. I admit, I used a converter when I edited
my headers lately.

>
> Admittedly, the whirlpool problem (BTW, now documented in
> FAQ Item 8.3) would be easy to solve with your proposal.
>
> Arno
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D
> 9718
> ----
> A good decision is based on knowledge and not on numbers. -  Plato
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Looking at the steps to solve the whirlpool issue basicly triggered the
idea (Even though I am not affected). And thanks for keeping the FAQ
current and for your work on it in general, I am sure it helps a lot of
people.

-Sven

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Arno Wagner]

On Fri, Feb 28, 2014 at 23:06:30 CET, Sven Eschenberg wrote:
> On Fri, February 28, 2014 22:46, Arno Wagner wrote:
> > On Fri, Feb 28, 2014 at 22:26:03 CET, Sven Eschenberg wrote:
> >> Just out of curiosity,
> >>
> >> Isn't it possible (yet) to override header fields during luksopen? If
> >> not,
> >> wouldn't it make sense to add something like that in future versions? I
> >> think it could be of great help when the header is partly damaged, to be
> >> able to override things without using a hex editor.
> >
> > I doubt this makes much sense. From what I have seen,
> > usually the magic string at the start is gone as well,
> > and then there is a real risk that people try this with
> > the wrong data. Using a hex-editor is not that hard and
> > using a hex-dumper is basically required to get any
> > reasonable form of diagnostics. Even the keyslot-
> > checker is basically a specialized hexdump tool.
> 
> Okay, that's true. I personally do use a hexeditor too, I have to admit,
> just thought it could help less experienced people. Then again, if people
> fail to use a hex editor chances are big they make things worse. I guess I
> didn't think this through long enough.

I have a _lot_ of experience with students, some not so bright
or experienced ;-)
 
> >> I am aware that one could use the non-LUKS mode to open a LUKS device by
> >> passing all required parameters, admitted. But a mode where one can use
> >> what's in the header and override single fields could be interesting.
> >> Once
> >> the correct params are determinde this way, one could maybe add an
> >> option
> >> to repair the header with the given replacements (Maybe by adding the
> >> option to reencryt?).
> >>
> >> Just some thoughts that crossed my mind.
> >
> > I doubt this really helps. Also remember that finding out what
> > actually broke the header is important, so fiddeling around
> > with an opaque header and commandline arguments to cryptsetup
> > after you have analyzed a hexdump strikes me as not that effective.
> 
> That's absolutely true, indeed.
> 
> >
> > I do understand that hex-editing is akward for many people,
> > but I do not think this makes it any better or clearer.
> > One thing that would help a bit is a header layout with
> > hex offsets. I think I am going to add that to the FAQ.
> 
> Good point, I'd propose adding this to the luks on disk format document as
> well. If you cannot convert HEX<->DEC inside your head having the hex
> offsets at disposal helps alot. I admit, I used a converter when I edited
> my headers lately.

Me too. For the time being, there now is a nice hex + dec table
in FAQ Item 6.12

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Sven Eschenberg]

Another things that crossed my mind:

Currently the FAQ states in respect to the whirpool problem, to do a
header backup prior to changing the header or using reencrypt. Wouldn't it
be better to make this a minimum requirement and recommend a full backup
instead? Imagine for whatever reason some portion after the payload offset
gets damaged/overwritten, be it by mixing up numbers or because of any
unobvious bug somewhere.

Regards

-Sven


On Sat, March 1, 2014 00:27, Arno Wagner wrote:
> On Fri, Feb 28, 2014 at 23:06:30 CET, Sven Eschenberg wrote:
>> On Fri, February 28, 2014 22:46, Arno Wagner wrote:
>> > On Fri, Feb 28, 2014 at 22:26:03 CET, Sven Eschenberg wrote:
>> >> Just out of curiosity,
>> >>
>> >> Isn't it possible (yet) to override header fields during luksopen? If
>> >> not,
>> >> wouldn't it make sense to add something like that in future versions?
>> I
>> >> think it could be of great help when the header is partly damaged, to
>> be
>> >> able to override things without using a hex editor.
>> >
>> > I doubt this makes much sense. From what I have seen,
>> > usually the magic string at the start is gone as well,
>> > and then there is a real risk that people try this with
>> > the wrong data. Using a hex-editor is not that hard and
>> > using a hex-dumper is basically required to get any
>> > reasonable form of diagnostics. Even the keyslot-
>> > checker is basically a specialized hexdump tool.
>>
>> Okay, that's true. I personally do use a hexeditor too, I have to admit,
>> just thought it could help less experienced people. Then again, if
>> people
>> fail to use a hex editor chances are big they make things worse. I guess
>> I
>> didn't think this through long enough.
>
> I have a _lot_ of experience with students, some not so bright
> or experienced ;-)
>
>> >> I am aware that one could use the non-LUKS mode to open a LUKS device
>> by
>> >> passing all required parameters, admitted. But a mode where one can
>> use
>> >> what's in the header and override single fields could be interesting.
>> >> Once
>> >> the correct params are determinde this way, one could maybe add an
>> >> option
>> >> to repair the header with the given replacements (Maybe by adding the
>> >> option to reencryt?).
>> >>
>> >> Just some thoughts that crossed my mind.
>> >
>> > I doubt this really helps. Also remember that finding out what
>> > actually broke the header is important, so fiddeling around
>> > with an opaque header and commandline arguments to cryptsetup
>> > after you have analyzed a hexdump strikes me as not that effective.
>>
>> That's absolutely true, indeed.
>>
>> >
>> > I do understand that hex-editing is akward for many people,
>> > but I do not think this makes it any better or clearer.
>> > One thing that would help a bit is a header layout with
>> > hex offsets. I think I am going to add that to the FAQ.
>>
>> Good point, I'd propose adding this to the luks on disk format document
>> as
>> well. If you cannot convert HEX<->DEC inside your head having the hex
>> offsets at disposal helps alot. I admit, I used a converter when I
>> edited
>> my headers lately.
>
> Me too. For the time being, there now is a nice hex + dec table
> in FAQ Item 6.12
>
> Arno
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D
> 9718
> ----
> A good decision is based on knowledge and not on numbers. -  Plato
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Milan Broz]

On 03/01/2014 08:39 AM, Sven Eschenberg wrote:
> Another things that crossed my mind:
> 
> Currently the FAQ states in respect to the whirpool problem, to do a
> header backup prior to changing the header or using reencrypt. Wouldn't it
> be better to make this a minimum requirement and recommend a full backup
> instead? Imagine for whatever reason some portion after the payload offset
> gets damaged/overwritten, be it by mixing up numbers or because of any
> unobvious bug somewhere.

Yes. But even better is to do this on backup header file (do not even try to touch
device), try with detached --header for open and once it works, put it back.
But this is way more complicated (but safe).


For the automatic repair, I was thinking about it, there are few more more points:

- there is no way how to check that keyslot uses flawed whirlpool
(except to check both and only if we get correct key with flawed on we know for sure).

In the beginning we only now that it is currently running on system
with flawed or fixed gcrypt. (It says nothing about where it was formatted.)
Slowing down all users is not option for me. And luksOpen should not
write anything to header.
(And I know RHEL did another backported fix for old gcrypt whit checks some
environment variable... So the logic will not work there.)

- other backends (like OpenSSL) do no have this problem, you will
never be able to open such device there.

- it is very rare problem (Arch is more affected by it because someone
suggested this hash on some installation page, copy&paste problem.)
(I would say - this is a good lesson to think why there are safe defaults
and why you should not change encryption parameters without good reason :-)

- the fix I implemented (specific name) is isolated in gcrypt backend,
all other backends will reject it as unknown hash instead of trying
(correctly, they have no such flawed algorithm) and people clearly
see it from header that something is wrong.

So the additional option I considered is to add some option to "repair"
or reencrypt command (user must run it explicitly).

TBH I do not think it is worth to do it. If we have more reports,
I would prefer specific script which will wrap command safely.


And definitely we need to compile cryptsetup with gcrypt 1.6.1
for this exercise, it is still not common in distros.

(BTW anyone from Gentoo here? Gcrypt 1.6.1 is masked out globally and
all I get to my query was it doesn't boot and "there's some other rather
nasty bugreports filed for newer cryptsetup". No more info...)

Milan

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Sven Eschenberg]

Hi Milan,

There seems to be a problem with cryptsetup 1.6.3 and libgcrypt>=1.6.0
causing a segmentation fault on gentoo. I don't know any more details
though. It is noted in the reason for the masking by the package
maintainer but there does not seem to be any bug report to substanciate
this.

Regards

-Sven

P.S.: It is not even clear what profiles and flavors are affected.

On Sat, March 1, 2014 09:35, Milan Broz wrote:
>
> (BTW anyone from Gentoo here? Gcrypt 1.6.1 is masked out globally and
> all I get to my query was it doesn't boot and "there's some other rather
> nasty bugreports filed for newer cryptsetup". No more info...)
>
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Arno Wagner]

Well, yes. But anybody careful or having read and understood
the warnings in the FAQ will have a full backup anyays. Anybody
that runs without backup is unlikely to make one now. Doing 
backup is sort of like working safely: It is a state of mind. 
One remark is not going to make people careful that are careless.

But I will add it nonetheless.

Arno

On Sat, Mar 01, 2014 at 08:39:44 CET, Sven Eschenberg wrote:
> Another things that crossed my mind:
> 
> Currently the FAQ states in respect to the whirpool problem, to do a
> header backup prior to changing the header or using reencrypt. Wouldn't it
> be better to make this a minimum requirement and recommend a full backup
> instead? Imagine for whatever reason some portion after the payload offset
> gets damaged/overwritten, be it by mixing up numbers or because of any
> unobvious bug somewhere.
> 
> Regards
> 
> -Sven
> 
> 
> On Sat, March 1, 2014 00:27, Arno Wagner wrote:
> > On Fri, Feb 28, 2014 at 23:06:30 CET, Sven Eschenberg wrote:
> >> On Fri, February 28, 2014 22:46, Arno Wagner wrote:
> >> > On Fri, Feb 28, 2014 at 22:26:03 CET, Sven Eschenberg wrote:
> >> >> Just out of curiosity,
> >> >>
> >> >> Isn't it possible (yet) to override header fields during luksopen? If
> >> >> not,
> >> >> wouldn't it make sense to add something like that in future versions?
> >> I
> >> >> think it could be of great help when the header is partly damaged, to
> >> be
> >> >> able to override things without using a hex editor.
> >> >
> >> > I doubt this makes much sense. From what I have seen,
> >> > usually the magic string at the start is gone as well,
> >> > and then there is a real risk that people try this with
> >> > the wrong data. Using a hex-editor is not that hard and
> >> > using a hex-dumper is basically required to get any
> >> > reasonable form of diagnostics. Even the keyslot-
> >> > checker is basically a specialized hexdump tool.
> >>
> >> Okay, that's true. I personally do use a hexeditor too, I have to admit,
> >> just thought it could help less experienced people. Then again, if
> >> people
> >> fail to use a hex editor chances are big they make things worse. I guess
> >> I
> >> didn't think this through long enough.
> >
> > I have a _lot_ of experience with students, some not so bright
> > or experienced ;-)
> >
> >> >> I am aware that one could use the non-LUKS mode to open a LUKS device
> >> by
> >> >> passing all required parameters, admitted. But a mode where one can
> >> use
> >> >> what's in the header and override single fields could be interesting.
> >> >> Once
> >> >> the correct params are determinde this way, one could maybe add an
> >> >> option
> >> >> to repair the header with the given replacements (Maybe by adding the
> >> >> option to reencryt?).
> >> >>
> >> >> Just some thoughts that crossed my mind.
> >> >
> >> > I doubt this really helps. Also remember that finding out what
> >> > actually broke the header is important, so fiddeling around
> >> > with an opaque header and commandline arguments to cryptsetup
> >> > after you have analyzed a hexdump strikes me as not that effective.
> >>
> >> That's absolutely true, indeed.
> >>
> >> >
> >> > I do understand that hex-editing is akward for many people,
> >> > but I do not think this makes it any better or clearer.
> >> > One thing that would help a bit is a header layout with
> >> > hex offsets. I think I am going to add that to the FAQ.
> >>
> >> Good point, I'd propose adding this to the luks on disk format document
> >> as
> >> well. If you cannot convert HEX<->DEC inside your head having the hex
> >> offsets at disposal helps alot. I admit, I used a converter when I
> >> edited
> >> my headers lately.
> >
> > Me too. For the time being, there now is a nice hex + dec table
> > in FAQ Item 6.12
> >
> > Arno
> > --
> > Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> > GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D
> > 9718
> > ----
> > A good decision is based on knowledge and not on numbers. -  Plato
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Heinz Diehl]

On 01.03.2014, Milan Broz wrote: 

> (I would say - this is a good lesson to think why there are safe defaults
> and why you should not change encryption parameters without good reason :-)

It's not always the facts which leads to action, but the peoples
assumptions and beliefs. After all, there's a general disbelief in all
things the NSA put their fingers on. That said, it is not hard for me
to understand what people moves to use whirlpool over SHAx..

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Arno Wagner]

On Sat, Mar 01, 2014 at 17:50:25 CET, Heinz Diehl wrote:
> On 01.03.2014, Milan Broz wrote: 
> 
> > (I would say - this is a good lesson to think why there are safe defaults
> > and why you should not change encryption parameters without good reason :-)
> 
> It's not always the facts which leads to action, but the peoples
> assumptions and beliefs. After all, there's a general disbelief in all
> things the NSA put their fingers on. That said, it is not hard for me
> to understand what people moves to use whirlpool over SHAx..

Which leads to its own set of problems, as recently seen...

The advice is not to change crypto parameters unless you
really know what you are doing. Most people do not and make
matters worse. The only thing we can try to do heres is to 
explain, as, e.g., FAQ Item 5.20 "LUKS is broken! It uses SHA-1!"
tries to do. Just changing some things with no clear understanding 
why they may or may not be bad is worse than running with the 
defaults. 

Face it, unless you are an experty for the use of crypto,
you have no chance of coocking up your own parameter set
that is reliably "better", but have a good chance of making 
things worse.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Heinz Diehl]

On 02.03.2014, Arno Wagner wrote: 

> > It's not always the facts which leads to action, but the peoples
> > assumptions and beliefs. After all, there's a general disbelief in all
> > things the NSA put their fingers on. That said, it is not hard for me
> > to understand what people moves to use whirlpool over SHAx..

> The advice is not to change crypto parameters unless you
> really know what you are doing. Most people do not and make
> matters worse.

It's perfectly clear to me (and I'm neither using whirlpool nor a
libgcrypt < 1.6.1). What I wanted to point out is that it seems to me
that people have lost their confidence in anything the NSA touched.
Thus, they seem to choose what they believe is most suitable, and not
what is based on facts.

> The only thing we can try to do heres is to 
> explain, as, e.g., FAQ Item 5.20 "LUKS is broken! It uses SHA-1!"
> tries to do.

I guess this is not sufficient, unless this is supplemented with a
clear statement on why they should trust something produced by the
NSA. That the recent attacks on SHA-1 are not relevant for
LUKS/dmcrypt is not the point, people understand that. SHA-x is
produced by the NSA, that's the problem. It's a matter of belief, not
facts. The whole Snowden case and all the articles, reports and other
media accompanying it shaped an overall statement: "You can't trust
the NSA". I guess the problem lies right here. And that is why people
choose e.g. whirlpool over the defaults.

There are many well-known theories and models which try to explain
and/or predict such behaviour, see e.g.

http://people.umass.edu/aizen/tpb.diag.html

(I for myself am quite comfortable with the defaults, because the only
purpose of encryption for me is to protect my data on my laptop in
case it gets stolen, and the defaults run fast on that machine. I do
not worry if the NSA has put a backdoor in SHA-1, because it would
hardly ever happen that the thief who stole my machine has that
insider knowledge to use it. So I consider my data to be safe in case 
my machine gets stolen, and that's all I want.)

Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

[Arno Wagner]

On Sun, Mar 02, 2014 at 08:35:23 CET, Heinz Diehl wrote:
> On 02.03.2014, Arno Wagner wrote: 
> 
> > > It's not always the facts which leads to action, but the peoples
> > > assumptions and beliefs. After all, there's a general disbelief in all
> > > things the NSA put their fingers on. That said, it is not hard for me
> > > to understand what people moves to use whirlpool over SHAx..
> 
> > The advice is not to change crypto parameters unless you
> > really know what you are doing. Most people do not and make
> > matters worse.
> 
> It's perfectly clear to me (and I'm neither using whirlpool nor a
> libgcrypt < 1.6.1). What I wanted to point out is that it seems to me
> that people have lost their confidence in anything the NSA touched.
> Thus, they seem to choose what they believe is most suitable, and not
> what is based on facts.

Indeed. Thereby they will often make themselves less secure and
play into the NSA's hands. A good eaxmple is SELinux. While
in theory it may be backdoored, doing so for an access control-layer 
is blatantly obvious, unlikely to have happened and easy to fix. 
If people now avoid SELinux because the NSA had a major part 
in its cration, they are making hemselves very much less secure 
and easier to attack, also for the NSA. 

Examples of NSA sabotage show that they want to be subtle and 
hard to detect reliably:

- Dual_EC_DRBG: They likely sabotaged the constants. This is 
  not detectable even for the very best experts. What experts 
  can do is suspect that the design allows undetectable attackable
  constants. (By now somebody has proven this by providing
  compromised constants and then attacking them.) Experts have 
  been suspicuous of this thing for a long time because of its
  design. And then there is the little gem, that in the
  implementation by RSA Labs it was the default, despite
  having the worst characteristics of the alternatives.
  That is highly telling and it is clear that at least
  some people at RSA Labs were in bed with the NSA.

- Intel RDRand: While it is unclear whether it has been 
  backdoored, the design intentionally makes it impossible
  to detect in software if it has. There is no sane reason 
  to do so, just an irrational end emotional appeal along the
  lines that "somebody could use this to attack RDRand if 
  its internal state was exposed via JTAG". That is of course
  complete BS, than anybody having JTAG access has physical
  access to the CPU busses at that time and can do anything 
  they like. Contrast that to the VIA C3 hardware random 
  number generator where you can read raw bits and see, 
  for example, influence of thermal shift.
  Just like for Dual_EC_DRBG it is unclrear whether RDRand
  has actually be compromised, but it clearly is prepared
  to be compromised easily and in a hard to detect fasion.
  I.e. it is insecure by design.
  It may never be compromised, it may be compromised for 
  specific batches of chips only, or it may be routinely 
  compromised from some point in time onwards. We cannot 
  easily find out and that is the problem.
  There is one non-technical clear indicator of sabotage
  though: There was a strong push by Intel egnineers to make
  the Linux kernel use RDRand exclusively for randomness
  generation and to drop all other ways of entropy gathering.
  There is no good technical reason for doing so (there
  are a lot of good reasons for _not_ doing so) and the
  Linux kernel folks recognized that and refused. But the
  pressure applied is in itself already quite telling.

- IPv6: The NSA sabotaged it not by introducing any direct flaw,
  but by making it convoluted and complex, thereby making it
  very vulnerable to implementation errors due to extreme 
  violation of the KISS principle and unneeded complexity.
  They likely go over the popular implementation from time 
  to time to have a nice liost of zero-day exploits ready 
  whenever they need them.

In all cases, sabotage cannot be reliably demonstrated, but 
it is pretty clear it happend or there was preparation for it.
Of course, it is possible that Dual_EC_DRBG and RDRand is
secure and they were just testing the waters whether the
community would accept a design with serious vulnerabilities
against the designer. It is even poossible that the 
anti-KISS attack against IPv6 is in fact incompetence. But 
how likely is that? Right, not at all. Hanlon's razor is
a good first evaluation for the actions of individuals,
but an organization like the NSA is very well capable 
of hiding behind it. 

Now take other things: 

- AES: There is really no reason to believe the NSA did 
  compromise it. It would have been hard, the risks of 
  being found out would have been quite real, and
  the damage to US and world economy could have been 
  catastrophic. 

- SELinux: Far too high a risk of them being found out.

So there is a pattern. And the Snowden documents confirm it.

Now an example where I am highly suspicuous of sabotage:

- systemd: It follows the example of IPv6 by violating KISS.
  It creates a high level of unneeded complexity, by doing
  a lot of things that should have been done seperately, just 
  like for IPv6, thereby making it a lot more prone to 
  vulerabilities to exploit by the NSA (and others). It sits 
  at a central control position and is implemented in C, giving
  it at least some level of obfusction, especially compared to
  the set of smaller shell-scripts used before. Just like for 
  RDRand there is high pressure being applied to variopus people 
  to make it the one thing to use and to drop all alternatives,
  an in fact to make it hard to use any alternative. 
  There are more similarities with other NSA sabotage efforts 
  and, at least to me, there is a high likelihood it is sabotage 
  with the intent to make Linux easy to attack.

The problem here is, AFAIK, there is no known NSA involvement
with systemd at all, just the same as with RDRand. It is however
quite probable the NSA has gotten more careful and views hiding 
its involvement as critical part of sabotage efforts by now.

So shying away from everything you know the NSA touched does 
not make you more secure and it may make you miss out on some 
security that is actually good. The way to do this instead is
to look for the tell-tale signs of sabotage: With IPv6, 
Dual_EC_DRBG, RDRand, systemd, they are strong. For anybody 
security-concious, the advice would be to stay away. With 
SELinux, AES, the SHA family, etc. there are no telltales 
I am aware of, so continue using them.   

This is of course not a sure-fire thing. You may mis-detect
things as possibly sabotaged that are merely incompetently 
designed, for example RDRand or systemd. But if you want
to be secure, you should stay away from incompetent design 
anyways, so it _is_ good advice. 


Personal side-note: Thomas Bächler may respond to this 
because I say bad things about systemd. After a series of 
cheap emotional manipulation attempts from him via email 
that reek of having spawned from the NSA and GCHQ "How 
to manipulate people on the Internet" documents that became 
public just a few days later, I am not talking to him 
anymore and hence no responses from me to him will be 
forthcomming. Just in case anybody wonders. 
 

> > The only thing we can try to do heres is to 
> > explain, as, e.g., FAQ Item 5.20 "LUKS is broken! It uses SHA-1!"
> > tries to do.
> 
> I guess this is not sufficient, unless this is supplemented with a
> clear statement on why they should trust something produced by the
> NSA. That the recent attacks on SHA-1 are not relevant for
> LUKS/dmcrypt is not the point, people understand that. 

Sorry, but from my observations people do not understand that 
at all. And it is not only the recent attacks, SHA-1 would
have to have a very gross fundamental vulnerability to be a 
security issue in LUKS. It is unlike to have that, the NSA 
does not want a smoking gun found that points to it.

There is also a second problem here: I am a competent user of
cryptology, I am not a cryptologist. There are not too many of 
those around. Even for the absence of a gross vulnerability in 
SHA-1 I have to rely on what the academic crypto community says.
From the voiced early suspicions against Dual_EC_DRBG, I conclude
they have not all been compromised.

And there is a third problem: If I say "trust me, even if the 
NSA has made SHA-1 less secure, LUKS is still good.", the problem
is the "trust me". The NSA has managed to corrode the very fabric 
of society in a way no concentrated terrorist campaign could 
ever have hoped to by eroding fundamental trust. The best I can 
do is to give all the facts as I have them and tell people to form
their own opinion. 

Incidentally, that is what I did before the NSA's treason
against humanity became known. There should always be independent 
verification, even if only by a few users.
 
> SHA-x is produced by the NSA, that's the problem. 
> It's a matter of belief, not
> facts. The whole Snowden case and all the articles, reports and other
> media accompanying it shaped an overall statement: "You can't trust
> the NSA". I guess the problem lies right here. And that is why people
> choose e.g. whirlpool over the defaults.

And that is the wrong approach. Even if you cannot trust the 
NSA, compromising crypto-hashes by design in a non-obvious (!) 
way is very hard, as is, for example, compromising block-ciphers.

For LUKS, the usage makes it a lot harder still. 
 
> There are many well-known theories and models which try to explain
> and/or predict such behaviour, see e.g.
> 
> http://people.umass.edu/aizen/tpb.diag.html

Yes. I understand that. The only thing I can do is to
say "you are doing it wrong" and to try to explain why.
And for those that have already shot themselves in the 
foot to help them recovering from it. 

I do know that there is no way to prevent some class of
people from panic-reactions, and I also do know that
triggering these panic reactions is something done by
highly competent attackers as amatter od routine. Hell, 
it es even used widerly in politics and advertizing and 
almost never fails to deliver.

Arno




> (I for myself am quite comfortable with the defaults, because the only
> purpose of encryption for me is to protect my data on my laptop in
> case it gets stolen, and the defaults run fast on that machine. I do
> not worry if the NSA has put a backdoor in SHA-1, because it would
> hardly ever happen that the thief who stole my machine has that
> insider knowledge to use it. So I consider my data to be safe in case 
> my machine gets stolen, and that's all I want.)



-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato