= System Wide Change: Replace glibc's libcrypt with libxcrypt = https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
Change owner(s): * Björn Esser <besser82 AT fedoraproject DOT org,> * Florian Weimer <fweimer AT redhat DOT com>
There are plans to remove libcrypt from glibc, so we should have a replacement.
== Detailed Description == Since there has been some discussion in the last time about removing libcrypt from glibc in some time and splitting it out into a separate project which can evolve quicker, Zack Weinberg and I put some work into libxcrypt to make it a basically suitable replacement.
It comes with a set of extended interfaces pioneered by Openwall Linux, crypt_rn, crypt_ra, crypt_gensalt, crypt_gensalt_rn, and crypt_gensalt_ra.
The crypt and gensalt functions are supporting all (except for Crypt16, which was used on Ultrix and Tru64, only) widely used password hashing algorithms, which before were specific to just some operating system's implementations of libcrypt.
== Scope == * Proposal owners: - Apply needed packaging changes to glibc - Review, import and build libxcrypt for Fedora 28
* Other developers: Test their applications using one of the following interfaces for unexpected changes in functionality: - crypt() - crypt_r() - encrypt() - encrypt_r() - fcrypt() - setkey() - setkey_r()
Release engineering: #7160 https://pagure.io/releng/issue/7160 none expected
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
On Tue, 9 Jan 2018 18:46:06 +0100, Jan Kurik wrote:
= System Wide Change: Replace glibc's libcrypt with libxcrypt = https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
Change owner(s):
- Björn Esser <besser82 AT fedoraproject DOT org,>
- Florian Weimer <fweimer AT redhat DOT com>
There are plans to remove libcrypt from glibc, so we should have a replacement.
Please clarify what exactly the plan is.
To replace libcrypt with a compatible library and with a grace period for apps to stop using deprecated functions that may be removed in the future?
Or to replace libcrypt with an incompatible library immediately with no grace period?
The reason why I ask is that Claws Mail still uses encrypt() with the sole purpose of being able to decrypt old passwords. It doesn't convert them to different encryption algorithms automatically, unless the user changes the password, and it doesn't force the user to set a Master Password either. Only the latter would add security since Claws Mail 3.14.0 (2016), which added that as a new feature.
On Mon, Jan 29, 2018 at 03:38:00PM +0100, Michael Schwendt wrote:
On Tue, 9 Jan 2018 18:46:06 +0100, Jan Kurik wrote:
= System Wide Change: Replace glibc's libcrypt with libxcrypt = https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
Change owner(s):
- Björn Esser <besser82 AT fedoraproject DOT org,>
- Florian Weimer <fweimer AT redhat DOT com>
There are plans to remove libcrypt from glibc, so we should have a replacement.
Please clarify what exactly the plan is.
To replace libcrypt with a compatible library and with a grace period for apps to stop using deprecated functions that may be removed in the future?
Or to replace libcrypt with an incompatible library immediately with no grace period?
The reason why I ask is that Claws Mail still uses encrypt() with the sole purpose of being able to decrypt old passwords. It doesn't convert them to different encryption algorithms automatically, unless the user changes the password, and it doesn't force the user to set a Master Password either. Only the latter would add security since Claws Mail 3.14.0 (2016), which added that as a new feature.
virt-customize is in a similar situation, except that we are also writing passwords on very old operating system images that require crypt(3).
One thing we had a bug report about was the old virt-builder and virt-customize binaries segfaulting with the new glibc. This turns out because crypt(3) in the new glibc is still there but always(?) returns NULL which unfortunately our code wasn't expecting ... Something to be aware of anyway.
I have since modified virt-customize to use libxcrypt.
Rich.
On Mon, 29 Jan 2018 15:38:00 +0100, Michael Schwendt wrote:
On Tue, 9 Jan 2018 18:46:06 +0100, Jan Kurik wrote:
= System Wide Change: Replace glibc's libcrypt with libxcrypt = https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
Change owner(s):
- Björn Esser <besser82 AT fedoraproject DOT org,>
- Florian Weimer <fweimer AT redhat DOT com>
There are plans to remove libcrypt from glibc, so we should have a replacement.
Please clarify what exactly the plan is.
To replace libcrypt with a compatible library and with a grace period for apps to stop using deprecated functions that may be removed in the future?
Or to replace libcrypt with an incompatible library immediately with no grace period?
The reason why I ask is that Claws Mail still uses encrypt() with the sole purpose of being able to decrypt old passwords. It doesn't convert them to different encryption algorithms automatically, unless the user changes the password, and it doesn't force the user to set a Master Password either. Only the latter would add security since Claws Mail 3.14.0 (2016), which added that as a new feature.
I had hoped there would be a response to this. Another try with the two change owners in Cc.
On 01/29/2018 03:38 PM, Michael Schwendt wrote:
The reason why I ask is that Claws Mail still uses encrypt() with the sole purpose of being able to decrypt old passwords. It doesn't convert them to different encryption algorithms automatically, unless the user changes the password, and it doesn't force the user to set a Master Password either. Only the latter would add security since Claws Mail 3.14.0 (2016), which added that as a new feature.
Which cryptographic library does Claws Mail use to implement the other encryption algorithm?
Thanks, Florian
On Fri, 9 Mar 2018 16:14:39 +0100, Florian Weimer wrote:
On 01/29/2018 03:38 PM, Michael Schwendt wrote:
The reason why I ask is that Claws Mail still uses encrypt() with the sole purpose of being able to decrypt old passwords. It doesn't convert them to different encryption algorithms automatically, unless the user changes the password, and it doesn't force the user to set a Master Password either. Only the latter would add security since Claws Mail 3.14.0 (2016), which added that as a new feature.
Which cryptographic library does Claws Mail use to implement the other encryption algorithm?
GnuTLS
On 03/09/2018 04:26 PM, Michael Schwendt wrote:
On Fri, 9 Mar 2018 16:14:39 +0100, Florian Weimer wrote:
On 01/29/2018 03:38 PM, Michael Schwendt wrote:
The reason why I ask is that Claws Mail still uses encrypt() with the sole purpose of being able to decrypt old passwords. It doesn't convert them to different encryption algorithms automatically, unless the user changes the password, and it doesn't force the user to set a Master Password either. Only the latter would add security since Claws Mail 3.14.0 (2016), which added that as a new feature.
Which cryptographic library does Claws Mail use to implement the other encryption algorithm?
GnuTLS
GnuTLS uses Nettle, but does not provide access to DES. You can use Nettle directly:
https://www.lysator.liu.se/~nisse/nettle/nettle.html#DES
OpenSSL will work as well, but as Nettle is a preexisting dependency, it's probably the right choice here.
Thanks, Florian
On Fri, 9 Mar 2018 16:32:17 +0100, Florian Weimer wrote:
GnuTLS uses Nettle, but does not provide access to DES. You can use Nettle directly:
https://www.lysator.liu.se/~nisse/nettle/nettle.html#DES
OpenSSL will work as well, but as Nettle is a preexisting dependency, it's probably the right choice here.
They don't seem to be compatible.
Whereas Nettle is fully compatible with glibc's rpc/des_crypt.h API, it offers a completely different interface than encrypt(), which operates on arrays of 64 bytes for each 64-bit block of input.
The ciphertext returned by encrypt() differs compared with Nettle and des_crypt (and that's with the bit vector transformation from the man page).
On Mon, 12 Mar 2018 13:12:49 +0100, Michael Schwendt wrote:
On Fri, 9 Mar 2018 16:32:17 +0100, Florian Weimer wrote:
GnuTLS uses Nettle, but does not provide access to DES. You can use Nettle directly:
https://www.lysator.liu.se/~nisse/nettle/nettle.html#DES
OpenSSL will work as well, but as Nettle is a preexisting dependency, it's probably the right choice here.
They don't seem to be compatible.
Whereas Nettle is fully compatible with glibc's rpc/des_crypt.h API, it offers a completely different interface than encrypt(), which operates on arrays of 64 bytes for each 64-bit block of input.
The ciphertext returned by encrypt() differs compared with Nettle and des_crypt (and that's with the bit vector transformation from the man page).
The example in "man encrypt" is the culprit. It extracts the bits from each byte upwards into the bit vector, i.e. offset 0 = bit 0 from byte 0, offset 1 = bit 1 from byte 0, offset 2 = bit 2 from byte 0 and so on.
If doing it as in the Claws Mail source code, the ciphertext is the same for all three DES APIs. Claws Mail unpacks the bits in decreasing (!) order.
That looks promising.
$ ./encrypt passkey = passkey0 Before encrypting: eggplant After encrypting: fd 1a 5d 03 ad e5 a6 c2 After decrypting: eggplant $ ./des_crypt passkey = passkey0 Before encrypting: eggplant After encrypting: fd 1a 5d 03 ad e5 a6 c2 After decrypting: eggplant $ ./nettle passkey = passkey0 Before encrypting: eggplant After encrypting: fd 1a 5d 03 ad e5 a6 c2 After decrypting: eggplant
The example in "man encrypt" is the culprit. It extracts the bits from each byte upwards into the bit vector, i.e. offset 0 = bit 0 from byte 0, offset 1 = bit 1 from byte 0, offset 2 = bit 2 from byte 0 and so on.
If doing it as in the Claws Mail source code, the ciphertext is the same for all three DES APIs. Claws Mail unpacks the bits in decreasing (!) order.
That looks promising.
The following patch would be one solution: https://mschwendt.fedorapeople.org/claws-mail-3.16.0-encrypt-nettle.patch
Is anybody going to fix the errors this caused? Namely this one:
https://bugzilla.redhat.com/show_bug.cgi?id=1537140
Thx
Vít
Dne 9.1.2018 v 18:46 Jan Kurik napsal(a):
= System Wide Change: Replace glibc's libcrypt with libxcrypt = https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
Change owner(s):
- Björn Esser <besser82 AT fedoraproject DOT org,>
- Florian Weimer <fweimer AT redhat DOT com>
There are plans to remove libcrypt from glibc, so we should have a replacement.
== Detailed Description == Since there has been some discussion in the last time about removing libcrypt from glibc in some time and splitting it out into a separate project which can evolve quicker, Zack Weinberg and I put some work into libxcrypt to make it a basically suitable replacement.
It comes with a set of extended interfaces pioneered by Openwall Linux, crypt_rn, crypt_ra, crypt_gensalt, crypt_gensalt_rn, and crypt_gensalt_ra.
The crypt and gensalt functions are supporting all (except for Crypt16, which was used on Ultrix and Tru64, only) widely used password hashing algorithms, which before were specific to just some operating system's implementations of libcrypt.
== Scope ==
- Proposal owners:
- Apply needed packaging changes to glibc
- Review, import and build libxcrypt for Fedora 28
- Other developers:
Test their applications using one of the following interfaces for unexpected changes in functionality:
- crypt()
- crypt_r()
- encrypt()
- encrypt_r()
- fcrypt()
- setkey()
- setkey_r()
Release engineering: #7160 https://pagure.io/releng/issue/7160 none expected
- Policies and guidelines:
N/A (not needed for this Change)
- Trademark approval:
N/A (not needed for this Change)