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

[Milan Broz <gmazyland@gmail.com>]

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