You are not logged in.
I skipped my last point to save time a reencrypt-run takes.
Interesting issue. If the whirlpool is only used to hash the key; and not for the encryption per se; it should not be necessary to re-encrypt (which is dangerous besides). You should be able to just create an updated LUKS header.
Starting with luksHeaderBackup (so you can revert if you mess up), luksDump (check the data offset, must remain identical - will be either 2056 or 4096), --dump-master-key (for the master keyfile, dump this to a tmpfs so it won't leak somewhere), then luksFormat with the --master-key-file and --align-payload. Do this on a test file / test device first to verify that the data offset and such will be correct. If that looks okay, do it on the real device. Then see if it has your data when you open it. Restore your luksHeaderBackup otherwise.
I also haven't experienced this issue using aes-xts-plain:
aes-xts-plain doesn't support >2TB (or rather, the block cipher repeats). You should be using aes-xts-plain64 instead (which is the current default cipher I believe). If your device is <2TB you can also do this without reencrypting. If it's >2TB you'll have to reencrypt it starting at 2TB offset, if you want to switch.
Last edited by frostschutz (2014-01-21 00:09:16)
Offline
Starting with luksHeaderBackup (so you can revert if you mess up), luksDump (check the data offset, must remain identical - will be either 2056 or 4096), --dump-master-key (for the master keyfile, dump this to a tmpfs so it won't leak somewhere), then luksFormat with the --master-key-file and --align-payload. Do this on a test file / test device first to verify that the data offset and such will be correct. If that looks okay, do it on the real device. Then see if it has your data when you open it. Restore your luksHeaderBackup otherwise.
I've tried to reenact those steps. But I did not manage to use the dumped key, neither when writing it to an ascii file (the file seems to be interpreted as binary) or converting said file to binary via "xxd -r -p" ("can't read 32 bytes from file"). So in what format does --master-key-file expect the key? Is there an alternative way to re-encrypt only the header? I'm kind Re-encrypting the whole drive as this has failed in the past.
Currently I can access an encrypted drive with a version of cryptsetup compiled against an older libgcrypt. Will the bug emulation be present by default in upcoming versions of libgcrypt? If no, how would I go about enabling it?
Luks information:
Version: 1
Cipher name: twofish
Cipher mode: xts-essiv:sha256
Hash spec: whirlpool
Payload offset: 4096
MK bits: 256
Offline
It expects binary format for the --master-key-file, whereas the --dump-master-key does only ascii hex representation.
Example: (using Bash and mouse to copy-paste, cause I'm too lazy for awk)
# cryptsetup luksDump --dump-master-key foobar
[...]
MK dump: e3 9d e3 89 ae 80 0c e2 e8 3d a4 09 42 2f a8 79
1f 37 4d d6 02 87 02 59 d2 c4 05 77 38 aa 1c 67
# echo " e3 9d e3 89 ae 80 0c e2 e8 3d a4 09 42 2f a8 79 1f 37 4d d6 02 87 02 59 d2 c4 05 77 38 aa 1c 67" | sed -e 's/ /\\x/g'
\xe3\x9d\xe3\x89\xae\x80\x0c\xe2\xe8\x3d\xa4\x09\x42\x2f\xa8\x79\x1f\x37\x4d\xd6\x02\x87\x02\x59\xd2\xc4\x05\x77\x38\xaa\x1c\x67
# echo -n $'\xe3\x9d\xe3\x89\xae\x80\x0c\xe2\xe8\x3d\xa4\x09\x42\x2f\xa8\x79\x1f\x37\x4d\xd6\x02\x87\x02\x59\xd2\xc4\x05\x77\x38\xaa\x1c\x67' > master.key
# hexdump -C master.key
00000000 e3 9d e3 89 ae 80 0c e2 e8 3d a4 09 42 2f a8 79 |.........=..B/.y|
00000010 1f 37 4d d6 02 87 02 59 d2 c4 05 77 38 aa 1c 67 |.7M....Y...w8..g|
00000020
Note: this leaks the master key to your bash history... (follow it up with a history -c if you're concerned) and on a multi user system, people could see it looking at 'ps', or reading your master.key file if you did not protect it.
Last edited by frostschutz (2014-01-22 16:24:50)
Offline
Thanks!
Well, now it worked without a hitch. I have no idea what went wrong with my xxd approach though. Probably rouge whitespace or something...
Offline
Glad it worked.
Offline
Hi, just wanted to add that in cryptsetup 1.6.4 now there is a compatibility feature to work around the error with the faulty whirlpool. The method to use it and correct the error is described in the cryptsetup faq, item: 8.3 Gcrypt after 1.5.3 breaks Whirlpool
Offline