Hello, After system update LUKS setup became a nightmare: it was impossible to mount LUKS partition (e.g. $HOME), thus affected system became useless and important data were on the verge of extinction. After an ordinary logout (while debugging cups issue I needed to restart dbus and thus Xorg and thus to umount LUKS volume using pam_umount) turned into inability to make actual login not to mention premature gray hair gained (when your password fails to work with your data out of the blue, this is no fun at all). After 4 hours of debugging here is a way to reproduce this: 1) Create encrypted LUKS volume using <=libgcrypt-1.5.3 and _any_ cryptsetup version (please note that you need to rebuild cryptsetup after each libgcrypt change in order to use installed version of the library and not those saved for you by preserved-libs). # This is just a test, so parameters non-relevant to the bug are not secure dd if=/dev/zero of=test.image bs=4M count=50 losetup -f test.image # let's assume you have /dev/loop1 at this point; # kernel must have support for: twofish, xts, whirlpool; # now create a test volume: cryptsetup luksFormat -c twofish-xts-plain:whirlpool -h whirlpool -s 256 -i 2 /dev/loop1 # You may test that it works: cryptsetup luksOpen /dev/loop1 test cryptsetup luksClose test 2) Now update libgcrypt to the latest 1.6.0 (and do not forget to rebuild cryptsetup): emerge -1 libgcrypt cryptsetup # and now you have: cryptsetup luksOpen /dev/loop1 test No key available with this passphrase. [You may try as long as you want... in vain...] Software compiles fine, works fine (no segfaults, etc), just *your* password doesn't work now... Such stuff may make people cry in the night... This bug depends only on libgcrypt version (and maybe on cipher/hash/modes used), bun not on: - kernel version (I tested from 3.2.23 from system rescue cd to 3.12.6 on my system); - cryptsetup version (older versions behave the same way as the latest with both old and new libgcrypt); - CFLAGS/CXXFLAGS/LDFLAGS used (mine flags are quite aggressive, but they never caused runtime failure, verified by recompilation of libgcrypt and cryptsetup with CFLAGS="-O2" CXXFLAGS="-O2" LDFLAGS="-Wl,-O1,--as-needed".
Created attachment 367532 [details] emerge --info
If possible, please attach a LUKS container which demonstrates the issue that you are seeing.
Created attachment 367556 [details] test.image.xz Hi, here is a test LUKS image, password: 12345
I also have this problem. It is affecting all of my systems. With libgcrypt 1.6.0, luksOpen hangs. This seems to affect both cryptsetup 1.6.2 and 1.6.3, which are the only ones I tried. As soon as I revert to libgcrypt 1.5.3, everything starts working again. I will be attaching debug output from cryptsetup with both libgcrypt 1.5.3 (working) and 1.6.0 (not working), plus modified output from strace, which shows the program entering an infinite loop reading from my keyfile (I edited out all but a handful of reads since it is a live key).
Created attachment 367598 [details] Debug output from cryptsetup with gcrypt 1.5.3
Created attachment 367600 [details] Debug output from cryptsetup with gcrypt 1.6.0
Created attachment 367602 [details] strace output from cryptsetup with gcrypt 1.6.0
Hi, I hit a similarproblem with this lib My Bug is perfectly described there: https://code.google.com/p/cryptsetup/issues/detail?id=199 Unlock takes up to 5 hours on my system :-(
This was fixed in libgcrypt upstream git: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=patch;h=04cda6b7cc16f3f52c12d9d3e46c56701003496e I can confirm that applying this patch allows me to boot :)
Thanks! applied to libgcrypt-1.6.0-r1.
Hello, looks like this bug became a collection of multiple libgcrypt related issues. While the last issue with too slow PBKDF2 is probably solved, original issue I reported is not: I updated to libgcrypt-1.6.1 (and rebuilt cryptsetup) and my passwords became invalid again. To verify this issue one may use a LUKS image and password from comment #3: it works for me with libgcrypt-1.5.3 and still fails with 1.6.1. (Please note that cryptsetup must be rebuild after each libgcrypt version change to reproduce this issue.)
Any explanation for why libgcrypt was globally blocked in packages.mask if just restricting the dependency in cryptsetup would most likely suffice? I use cryptsetup with use=-gcrypt, and i never had a problem with my luks volumes.
(In reply to Marcin Kowalski from comment #12) > Any explanation for why libgcrypt was globally blocked in packages.mask if > just restricting the dependency in cryptsetup would most likely suffice? There is a high probability that cryptsetup is not the only one broken application. It is the most widely used (at least at a system-wide scale).
(In reply to Andrew Savchenko from comment #0) > This bug depends only on libgcrypt version (and maybe on cipher/hash/modes > used) Because of the global mask I tried to reproduce your problem and now I can confirm that I see the same problem on all systems I tried, but only with twofish/xts-plain:whirlpool from your test case. I am unable to reproduce the problem when I create a volume with the following command: # cryptsetup --verbose --cipher=aes-xts-plain64 --hash=sha512 --key-size=512 --iter-time=4444 --verify-passphrase luksFormat So it must have something to do with the cipher/modes/hash.. Have you seen https://code.google.com/p/cryptsetup/issues/detail?id=200 ? If this is your problem it looks like an invalid bug, not?
Hello, (In reply to Thomas D. from comment #14) > Because of the global mask I tried to reproduce your problem and now I can > confirm that I see the same problem on all systems I tried, but only with > twofish/xts-plain:whirlpool from your test case. > > I am unable to reproduce the problem when I create a volume with the > following command: > > # cryptsetup --verbose --cipher=aes-xts-plain64 --hash=sha512 --key-size=512 > --iter-time=4444 --verify-passphrase luksFormat > > > So it must have something to do with the cipher/modes/hash.. That's a good clue, but nevertheless all ciphers, hashes and their combinations should be supported (unless some of them are explicitly marked as unsupported by upstrem). > Have you seen https://code.google.com/p/cryptsetup/issues/detail?id=200 ? If > this is your problem it looks like an invalid bug, not? What I see there is that there is a whirlpool bug in libgcrypt < 1.6 which is fixed improperly (in a way, that broke backwards compatibility and people's data; and does so even without any warning). So this fix is a bug itself. While cryptsetup have patches to support both whirlpool implementations and functionality to reencrypt LUKS header only (commits 461011ad2a64 through 75c105f85355), these commits are still not released and I prefer to wait till the next cryptsetup release to test this. So, until new cryptsetup is released (or all appropriate patches are applied to a current version) and some big fat warning is issued about _mandatory_ migration process for whirlpool users, this bug is perfectly valid. Meanwhile it looks like all applications using whirlpool and libgcrypt may be affected by this issue.
How can you fix something backward compatible, when I was broken beforehand? Are you expecting a fix, that keeps a broken whirlpool implementation including all it implies? (In reply to Andrew Savchenko from comment #15) > Hello, > > (In reply to Thomas D. from comment #14) > > Have you seen https://code.google.com/p/cryptsetup/issues/detail?id=200 ? If > > this is your problem it looks like an invalid bug, not? > > What I see there is that there is a whirlpool bug in libgcrypt < 1.6 which > is fixed improperly (in a way, that broke backwards compatibility and > people's data; and does so even without any warning). So this fix is a bug > itself. >
(In reply to Sven E. from comment #16) > How can you fix something backward compatible, when I was broken beforehand? You can detect old versions and handle them properly in order to fix decryption. You may warn users about upgrade requirement, but you have no right to broke peoples data, especially since we are in a cryptography realm. > Are you expecting a fix, that keeps a broken whirlpool implementation > including all it implies? Please follow links from comment 15. Yes, I'm expecting this and this is *already done upstem*, though only in the git head and not released yes. And please do not top post.
(In reply to Andrew Savchenko from comment #17) > (In reply to Sven E. from comment #16) > > How can you fix something backward compatible, when I was broken beforehand? > > You can detect old versions and handle them properly in order to fix > decryption. You may warn users about upgrade requirement, but you have no > right to broke peoples data, especially since we are in a cryptography realm. > > > Are you expecting a fix, that keeps a broken whirlpool implementation > > including all it implies? > > Please follow links from comment 15. Yes, I'm expecting this and this is > *already done upstem*, though only in the git head and not released yes. > > And please do not top post. This libgcrypt is non stable, exactly to find these issues without effecting stable users. You are free to revert to sable until issue is resolved. I am unsure where you think this warning be, as far as I understand it should be where effected components are with explicit instructions of how to resolve the issue.
(In reply to Alon Bar-Lev from comment #18) > This libgcrypt is non stable, exactly to find these issues without effecting > stable users. You are free to revert to sable until issue is resolved. I am > unsure where you think this warning be, as far as I understand it should be > where effected components are with explicit instructions of how to resolve > the issue. IMO a magnitude of this accident is far beyond brokenness acceptable for unstable packages: systems became unusable and even unbootable. That is why we have masks for. Note, that when cryptsetup-1.6.4 will be released, proper migration instructions may be added and current mask reverted. See bug 500884 for details.
(In reply to Andrew Savchenko from comment #17) > (In reply to Sven E. from comment #16) > > How can you fix something backward compatible, when I was broken beforehand? > > You can detect old versions and handle them properly in order to fix > decryption. You may warn users about upgrade requirement, but you have no > right to broke peoples data, especially since we are in a cryptography realm. No data was or is broken, I think you have a strong misconception here (including the concept of one way functions). Detecting is not possible except with a major performance penalty, that's why cryptsetup will NOT do this automagically. > > > Are you expecting a fix, that keeps a broken whirlpool implementation > > including all it implies? > > Please follow links from comment 15. Yes, I'm expecting this and this is > *already done upstem*, though only in the git head and not released yes. > No it is not done upstream and will not be. All fixes aim at rehashing - while it is possible to stay with the broken implemenation, it will need you to hexedit your LUKS header or keep a broken libgcrypt as long as ypu are not rehashing.
(In reply to Sven E. from comment #20) > No data was or is broken, I think you have a strong misconception here > (including the concept of one way functions). Detecting is not possible > except with a major performance penalty, that's why cryptsetup will NOT do > this automagically. Why not? I propose to check REPLACING_VERSIONS in libgcrypt ebuild and to check libgcrypt version on cryptsetup install. Its not that hard. > > > > > Are you expecting a fix, that keeps a broken whirlpool implementation > > > including all it implies? > > > > Please follow links from comment 15. Yes, I'm expecting this and this is > > *already done upstem*, though only in the git head and not released yes. > > > > No it is not done upstream and will not be. All fixes aim at rehashing - > while it is possible to stay with the broken implemenation, it will need you > to hexedit your LUKS header or keep a broken libgcrypt as long as ypu are > not rehashing. Hmm, looks like some misunderstanding took place. I'm talking exactly about header's key slot reencryption. Of course, to get rid of broken whirlpool implementation one needs to rehash key with a proper one. My point is that libgcrypt-1.6.4 provides: 1) --keep-key options which allows to reencrypt LUKS header only without volume data reencryption; 2) support for both broken and fixed whirlpool implementations, which allows one to access previously created data. Meanwhile cryptsetup-1.6.4 was released few days ago and I'm going to test it soon.
Hi, I can tell that sys-fs/cryptsetup-1.6.4 only works together with dev-libs/libgcrypt-1.5.3 (the only version lower than 1.6.1 available for downgrade). Problem has been that cryptsetup segfaulted on "cryptsetup create" subcommand - which made my crypted data filesystem unusable. Downgrading dev-libs/libgcrypt to 1.5.3 followed by a rebuild of sys-fs/cryptsetup-1.6.4 makes cryptsetup usable again. I can provide more informations on request.
This problem is not seen here with cryptsetup-1.6.4 and libgrypt-1.6.1.
I solved my problem without reencryption of a whole partition, as I was going to do in my post above. cryptsetup encrypts two different objects via completely different means: 1) Data partition. It is encrypted using kernel crypto facilities and doesn't depend on either libgcrypt, openssl or nettle libraries. I use whirlpool hash together with xts cypher mode and still I don't need to do anything with this data. 2) Volume header encryption. This part encrypts volume keys with user passwords and may use userspace libraries, libgcrypt in my case. And this and only this object is broken. The following steps are needed to fix it without whole volume reencryption: 1. emerge -1 --ignore-built-slot-operator-deps y >=cryptsetup-1.6.4[reencrypt] after =libgcrypt-1.5.3. --ignore-built-slot-operator-deps y is needed, because otherwise blocks may occur during rebuild. This is only temporary downgrade, so it is safe to ignore rebuilds here. 2. cryptsetup-reencrypt --keep-key --hash <some algo other than whirlpool> <you volume> The key feature here is --keep-key option added in crypt-setup-1.6.4. 3. emerge -1 libgcrypt cryptsetup Just return the latest versions. 4. Optionally you may return whirlpool hash using fixed implementation: cryptsetup-reencrypt --keep-key --hash whirlpool <you volume> It would be wise to include these or similar in cryptsetup elog messages.
https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#8._Issues_with_Specific_Versions_of_cryptsetup
(In reply to Rick Farina (Zero_Chaos) from comment #25) > https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#8. > _Issues_with_Specific_Versions_of_cryptsetup right. nothing left for us here -- cryptsetup-1.6.5 in stable is good, long as people follow instructions from upstream
