Just out of curiosity, Isn't it possible (yet) to override header fields during luksopen? If not, wouldn't it make sense to add something like that in future versions? I think it could be of great help when the header is partly damaged, to be able to override things without using a hex editor. I am aware that one could use the non-LUKS mode to open a LUKS device by passing all required parameters, admitted. But a mode where one can use what's in the header and override single fields could be interesting. Once the correct params are determinde this way, one could maybe add an option to repair the header with the given replacements (Maybe by adding the option to reencryt?). Just some thoughts that crossed my mind. Regards -Sven On Fri, February 28, 2014 12:29, Milan Broz wrote: > On 02/27/2014 06:30 PM, Thomas Bächler 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. >> >> Thank you for your work on cryptsetup. >> >>> * 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. >> >> 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 > distro. > 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 > here: > > # cryptsetup luksDump <your luks device> --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 <your luks device> > > 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 > version) > > - now you need to change LUKS header hash name from "whirlpool" to > "whirlpool_gcryptbug" > (this requires manual overwrite). You can use hex editor or e.g. > > # echo -n -e 'whirlpool_gcryptbug\0' | dd of=<luks device> bs=1 seek=72 > conv=notrunc > > 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 > device > is compatible with older distros again. > > Milan > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
