Currently libgcrypt>=1.6.0 is masked: # /usr/portage/profiles/package.mask: # Patrick Lauer <patrick@gentoo.org> (07 Feb 2014) # Reliably makes cryptsetup segfault, breaking boot is not acceptable This ignores two facts: 1.) cryptsetup does not need libgcrypt, there's plenty of libgcrypt alternatives, just default to another backend. 2.) libcrypt hast a broken WP implementation that was triggered by cryptsetup. as long as libgcrypt<1.6.0 is kept as an option for cryptsetup, broken setups will keep growing. An appropriate solution could be to: 1.) Mask libgcrypt<1.6.0, unmask >=1.6.0 2.) For cryptsetup choose a different default backend for the time being 3.) for those users having +gcrypt on cryptsetup warn them that the old gcrypt libs have a broken WP and that they need to migrate (sooner or later) - they could still possibly unmask the old libgcrypt as an intermediate solution I still can see the problem with the segfault with newer libgcrypt, but do we really want to keep a broken hash implementation and lure more people into the trap of ending up with a broken setup? Reproducible: Always
Personally, I agree, we should port people to openssl until libgcrypt issues are resolved, but I am not the maintainer of cryptsetup.
Some more thoughts on this. libgcrypt has a bug ins it'S Ws implementation, to be more precicse in a specific modus operandi, which is used by cryptsetup in the KDF. As the function calculates wrong hash values there will be no way around rehashing. This does not only apply to cryptsetup, but every app using libgcrypt with WP in this modus operandi. If we would keep the broken libgcrypt were are just pushing this forward and newly created hashes will suffer from the bug and need to be converted in the long run. Eventually we would have to wait for all applications to work around this. Now, for the time being libgcrypt folks agreed to keep the broken implementation alongside the correct one and 'emulate' the broken behavior. I doubt though, that they will keep it forever. (Probably the lifetime of the current 1.6 tree will be the maximum time it will be available). As far as I can see it, only people with -h whirlpool are affected (while -c is handled by dmcrypt/kernel and cryptsetup has no role in this). The cryptsetup maintainer plans to offer a simple way to rehash and to setup a broken mapping (which will be called accordingly). Afaik useing such a broken mapping will get the user a lot of noise and whistle (which might be suppressable by batch option, I am not sure what the final plan will be), or in other words, it is planned to throw rocks into people's way to gently force em to migrate or rehash. In a way people who used gcrypt<1.6 and -h whirlpool are doomed one way or the other, they can wait (and hope for) a smooth/easy migration path but cannot circumvent it in the long run. At the same time every other backend will work the same as libgcrypt with the exception of libgcrypt+whirlpool. Even those who set up with libgcrypt 1.6 can switch backends for whirlpool. Everybody who used gcrypt and any other hash can switch backends too. One thing I might add, depending on how the bug changed the hash calculation the cryptographic quality of the hash values might have been compromised as well. In summary there is plenty of reason to mask libgcrypt<1.6 and it could easily be done by changing backends in cryptsetup. There is not much we can do for the doomed, but we can save people from ending up in the same situation and circumvent additional wrong hash values in other apps.
Hello, cryptsetup will have migration functionality available in 1.6.4 release: 1) old whirlpool hash function will be available together with fixed one; 2) it will be possible to rehash LUKS header without reencryption of the whole volume. See https://code.google.com/p/cryptsetup/source/browse/docs/v1.6.4-ReleaseNotes for details. When cryptsetup-1.6.4 will be put in tree, package maintainer should add ewarn (or even eerror) notes to crypsetup to explain whirlpoolusers how to migrate painlessly with new libgcrypt. Similar warning should be added to libgcrypt, explaining availability of both functions, how to find packages using libgcrypt and how to reencrypt data in the worst case scenario (when affected program doesn't support both whirlpool functions): downgrade libgcrypt to <1.6.0, rehash whirlpool with something else, upgrade libgcrypt to >=1.6.1, rehash with fixed whirlpool. When this point will be reached, <libgcrypt-1.6.1 should be masked. Please note: libgcrypt-1.6.0* should be masked as well, because its PBKDF2 implementation is unacceptably slow (it takes hours for people to decrypt something, see bug 497654 for details).
(In reply to Andrew Savchenko from comment #3) > Hello, > > cryptsetup will have migration functionality available in 1.6.4 release: > 1) old whirlpool hash function will be available together with fixed one; > 2) it will be possible to rehash LUKS header without reencryption of the > whole volume. > See > https://code.google.com/p/cryptsetup/source/browse/docs/v1.6.4-ReleaseNotes > for details. > > When cryptsetup-1.6.4 will be put in tree, package maintainer should add > ewarn (or even eerror) notes to crypsetup to explain whirlpoolusers how to > migrate painlessly with new libgcrypt. > > Similar warning should be added to libgcrypt, explaining availability of > both functions, how to find packages using libgcrypt and how to reencrypt > data in the worst case scenario (when affected program doesn't support both > whirlpool functions): downgrade libgcrypt to <1.6.0, rehash whirlpool with > something else, upgrade libgcrypt to >=1.6.1, rehash with fixed whirlpool. > > When this point will be reached, <libgcrypt-1.6.1 should be masked. Please > note: libgcrypt-1.6.0* should be masked as well, because its PBKDF2 > implementation is unacceptably slow (it takes hours for people to decrypt > something, see bug 497654 for details). There's absolutely no need to wait. People with Whirlpool can still unmask the old libgcrypt and wait for cryptsetup to be releasded. Additionally you can already easily rehash the LUKS header manually. In either way a full backup will be mandatory for the sake of (data) security. There's absolutely no reason to postpone this any longer, except screwing over more people (those who will decide to use whirlpool for -h). Sidenote, cryptsetup releases will be served via kernel.org from now on, starting with 1.6.4, which should be released in the next couple of days. Location: https://www.kernel.org/pub/linux/utils/cryptsetup/
(In reply to Sven E. from comment #4) > There's absolutely no need to wait. People with Whirlpool can still unmask > the old libgcrypt and wait for cryptsetup to be releasded. No, they can't. Because their systems will became unbootable and unusable. And there will be no warning or indication of the problem from both ebuild upgrade warnings and cryptsetup itself. When I was not able to boot properly due to this problem, the only thing I saw immediately that my LUKS password was no longer valid. That's terrible: I had to guess whether I have hardware double failure (all my disks are mirrored), software header damage or I was just hit by amnesia and forgot my password irrecoverably. Probably this is the worst software failure I had to deal with in the last 19 years. > Additionally you > can already easily rehash the LUKS header manually. In either way a full > backup will be mandatory for the sake of (data) security. It is possible, but no easily. Prior to commit https://code.google.com/p/cryptsetup/source/detail?r=e364041b40aabc9377d356df74bd8bd5c24f61c6 (which is on top of 1.6.3) it is possible to change LUKS header only with altogether with a whole volume reencryption. Have you ever tried to reencrypt 3TB of data on quite modest CPU and MB bus? > There's absolutely no reason to postpone this any longer, except screwing > over more people (those who will decide to use whirlpool for -h). Ebuild warning may be added to warn people. I'm OK with <libgcrypt-1.6.1 masking as soon as migration tools will be available and migration process will be documented for users.
(In reply to Andrew Savchenko from comment #5) > (In reply to Sven E. from comment #4) > > There's absolutely no need to wait. People with Whirlpool can still unmask > > the old libgcrypt and wait for cryptsetup to be releasded. > > No, they can't. Because their systems will became unbootable and unusable. > And there will be no warning or indication of the problem from both ebuild > upgrade warnings and cryptsetup itself. When I was not able to boot properly > due to this problem, the only thing I saw immediately that my LUKS password > was no longer valid. That's terrible: I had to guess whether I have hardware > double failure (all my disks are mirrored), software header damage or I was > just hit by amnesia and forgot my password irrecoverably. Probably this is > the worst software failure I had to deal with in the last 19 years. I guess you miosunderstood something here, I said people can unmask the old libgcrypt to stay with the masked broken version until they have an easier migration path, as it only applies to -h whirlpool. At the same time masking it will aboid nmore people gettign stuck with something broken. Well unfortunately cryptsetup had no knowledge of the broken hash function and there is no way to fix a hash function in a 'compatible' way. I am sure Milan had added a warning if he had known about it before or disabled whirlpool for key derivation with libgcrypt. > > > Additionally you > > can already easily rehash the LUKS header manually. In either way a full > > backup will be mandatory for the sake of (data) security. > > It is possible, but no easily. Prior to commit > https://code.google.com/p/cryptsetup/source/ > detail?r=e364041b40aabc9377d356df74bd8bd5c24f61c6 > (which is on top of 1.6.3) it is possible to change LUKS header only with > altogether with a whole volume reencryption. Have you ever tried to > reencrypt 3TB of data on quite modest CPU and MB bus? A Reencryption is not necessary, you can as well do what cryptsetup will provide in a 'simple' step manually, mainly: Extract masterkey, create new header with same masterkey, cipher etc. but different key derivation. Replace broken header. There's no magic in it, except that you'll need a handfull commands instead of one. > > > There's absolutely no reason to postpone this any longer, except screwing > > over more people (those who will decide to use whirlpool for -h). > > Ebuild warning may be added to warn people. I'm OK with <libgcrypt-1.6.1 > masking > as soon as migration tools will be available and migration process will be > documented for users. We'll need warnings etc. anyway, I guess. Of course the ebuild could scan the system for LUKS volumes hich use whirlpool in key derivation and check if the old cryptsetup was linked against libgcrypt with a broken implementation and only then warn the user, but that might be a little overkill.
(In reply to Sven E. from comment #0) > An appropriate solution could be to: > 1.) Mask libgcrypt<1.6.0, unmask >=1.6.0 > 2.) For cryptsetup choose a different default backend for the time being It seems that it was unmasked (1) without switching the default backend (2) or fixing whatever causes the segfault; thus cryptsetup luksOpen segfaults for ~amd64 users in some libgcrypt function currently. I started having this issue some time ago, but forgot about it (my daily backup script uses cryptsetup so I just copied my working initramfs binary into the system as a workaround). Put it out of my mind until someone had the same issue in IRC today. Added -gcrypt kernel to packages.use for cryptsetup as a workaround. Can anyone else reproduce this?
Just for the record, this issue only happens when you are using whirlpool AND the incremental hashing system. Also in many cases (including cryptsetup's usage) it isn't a security concern and were it is it is still quite a minor one. The reason for that is that it only affects the padding added to the data, this is basically a 1 byte followed with 0s and the 256bit length of the data introduced. This padding is usually added to make the result more dependent on the message length and make collisions harder (and also avoid trivial state extensions). So for uses like PBKDF where the only expected properties of the hash are that it is 1-way and provides a good mixing of the entropy this isn't an issue. It is a minor issue, though, if your intention is avoiding collisions (as the hash is no longer strictly dependant on the length of the input thus making collisions a bit more likely) or avoiding length-extension attacks (in which case you should have used HMAC to start with which wouldn't show this issue as whirlpool is vulnerable per se to such kinds of attack).
libgcrypt 1.6.x is currently stable, this bug is no longer applicable
