From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 OeecZYt3UBfy for ; Fri, 17 Jan 2014 21:58:10 +0100 (CET) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Fri, 17 Jan 2014 21:58:10 +0100 (CET) Received: by mail-ea0-f177.google.com with SMTP id n15so2009203ead.8 for ; Fri, 17 Jan 2014 12:58:10 -0800 (PST) Message-ID: <52D9995F.1070808@gmail.com> Date: Fri, 17 Jan 2014 21:58:07 +0100 From: Milan Broz MIME-Version: 1.0 References: <52D975A3.6080609@gmail.com> <87sismz76l.fsf@vigenere.g10code.de> In-Reply-To: <87sismz76l.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Whirlpool in gcrypt <= 1.5.3 broken (if writes in chunks)? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: gcrypt-devel@gnupg.org Cc: dm-crypt 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