From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <wk@gnupg.org>
Received: from mail.saout.de ([127.0.0.1])
 by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id dHrMppNYFP0j for <dm-crypt@saout.de>;
 Fri, 17 Jan 2014 22:18:48 +0100 (CET)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222])
 (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))
 (No client certificate requested)
 by mail.saout.de (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Fri, 17 Jan 2014 22:18:48 +0100 (CET)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2
 (Debian)) id 1W4G9I-0000ro-VN
 for <dm-crypt@saout.de>; Fri, 17 Jan 2014 21:36:17 +0100
From: Werner Koch <wk@gnupg.org>
References: <52D975A3.6080609@gmail.com>
Date: Fri, 17 Jan 2014 21:26:10 +0100
In-Reply-To: <52D975A3.6080609@gmail.com> (Milan Broz's message of "Fri, 17
 Jan 2014 19:25:39 +0100")
Message-ID: <87sismz76l.fsf@vigenere.g10code.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [dm-crypt] Whirlpool in gcrypt <= 1.5.3 broken (if writes in
	chunks)?
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: Milan Broz <gmazyland@gmail.com>
Cc: dm-crypt <dm-crypt@saout.de>, gcrypt-devel@gnupg.org

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 :-(

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). 

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).


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.