From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Fri, 28 Feb 2014 12:29:39 +0100 (CET) Received: by mail-ea0-f174.google.com with SMTP id h14so2570481eaj.33 for ; Fri, 28 Feb 2014 03:29:38 -0800 (PST) Message-ID: <5310731F.2080701@gmail.com> Date: Fri, 28 Feb 2014 12:29:35 +0100 From: Milan Broz MIME-Version: 1.0 References: <530F4E30.6000204@gmail.com> <530F7644.4040003@archlinux.org> In-Reply-To: <530F7644.4040003@archlinux.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Thomas_B=E4chler?= , dm-crypt@saout.de On 02/27/2014 06:30 PM, Thomas B=E4chler 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. >=20 > Thank you for your work on cryptsetup. >=20 >> * 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. >=20 > 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 dist= ro. 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 her= e: # cryptsetup luksDump --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 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 versi= on) - now you need to change LUKS header hash name from "whirlpool" to "whirl= pool_gcryptbug" (this requires manual overwrite). You can use hex editor or e.g. # echo -n -e 'whirlpool_gcryptbug\0' | dd of=3D bs=3D1 seek= =3D72 conv=3Dnotrunc 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 de= vice is compatible with older distros again. Milan