Re: [dm-crypt] Whirlpool in gcrypt <= 1.5.3 broken (if writes in chunks)?

[Milan Broz <gmazyland@gmail.com>]

On 01/17/2014 09:26 PM, Werner Koch wrote:
> On Fri, 17 Jan 2014 19:25, gmazyland@gmail.com said:
> 
>> Is my assumption that all whirlpool implementations before
>> libgcrypt 1.6.0 are broken if used this way?
> 
> Right.  Now why are you using a non-standard algorithm and then also hit
> the 62 byte problem :-(

Whirlpool was never default but people like to fiddle with things :)
No idea how many devices use this but with more systems using libgcrypt 1.6.0,
more problems will appear...

> Anyway, I see that we need to do something about it.  Changing the
> correct implementation is not a good idea but I would be possible to add
> a bug emulation flag.  We do something similar in GnuPG to workaround a
> pgp-2 incompatibility.
> 
> I can see two ways to implement it: If you only hash small amounts of
> data, retrying with the hash operation with the bug emulation flag set
> would be the easiest way.  The other option would be to implement a
> variant of Whirlpool with this bug not fixed.  Then you could add this
> as a second hash algorithm to the same context and hash only one.  That
> is practical for streamed data but it does not save time because it
> always hashes twice (could be optimized but we would end up with quite
> some complexity). 

The problem is in AF filter
http://code.google.com/p/cryptsetup/source/browse/lib/luks1/af.c
which uses hash to diffuse key to several encrypted sectors, hash is called
a lot of times there.

But I really do not care about speed here - the goal is create to some
easy way how to fix existing LUKS headers to work with new gcrypt.

> I would really prefer to add a bug emulation flag so that you could go
> and re-encrypt the data on the fly (using the fixed Whirlpool or SHA-x
> for better performance).

Yes, I prefer this as well. I had already code to reencrypt device, here we
need only to reencrypt header and keyslots.
I just need to have access to both whirlpool variants.

So if there is a "bug emulation flag" it could help to implement it.

Thanks,
Milan