Hello everyone,
since there has been some discussion in the last time about removing libcrypt from glibc in some time [1,2,3,4] and splitting it out into a separate project which can evolve quicker, I'd like to hear your oppinion about replacing glibc's libcrypt with libxcrypt [5] for Fedora 29 (or 30).
libxcrypt will be fully binary compatible with software linked against glibc's libcrypt and does not require any rebuilds. However, the converse is not true: programs linked against libxcrypt will not work with glibc's libcrypt. 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. Also, programs that use certain legacy APIs supplied by glibc's libcrypt (encrypt, encrypt_r, setkey, setkey_r, and fcrypt) cannot be compiled against libxcrypt.
The crypt and gensalt functions are supporting all (except for Crypt16, which was used on Ultrix and Tru64, only) widely used password hashing algorithms [6], which before were specific to just some operating system's implementations of libcrypt [7].
There are preperations to add password hashing with PBKDF2 using HMAC- SHA3-512 to libxcrypt as well.
Anyways, before this can happen, there is still some work to be done with libxcrypt, like adding a FIPS mode or FIPS compliance in a different way.
Cheers, Björn
[1] https://sourceware.org/ml/libc-alpha/2017-06/msg00055.html [2] https://sourceware.org/ml/libc-alpha/2017-06/msg00079.html [3] https://sourceware.org/ml/libc-alpha/2017-08/msg01257.html [4] https://sourceware.org/ml/libc-alpha/2017-08/msg01408.html [5] https://github.com/besser82/libxcrypt [6] https://en.wikipedia.org/wiki/Crypt_(C)#Key_derivation_functions_s upported_by_crypt [7] https://en.wikipedia.org/wiki/Crypt_(C)#Support_in_operating_syste ms
I forgot to mention: There's already a COPR [1] for sneak-peak testing of the current pre-release libxcrypt.
[1] https://copr.fedorainfracloud.org/coprs/besser82/libxcrypt/
On 2017-11-08 11:08, Björn 'besser82' Esser wrote:
since there has been some discussion in the last time about removing libcrypt from glibc in some time [1,2,3,4] and splitting it out into a separate project which can evolve quicker, I'd like to hear your oppinion about replacing glibc's libcrypt with libxcrypt [5] for Fedora 29 (or 30).
Is anyone besides us (committed to) using and contributing to libxcrypt?
libxcrypt will be fully binary compatible with software linked against glibc's libcrypt and does not require any rebuilds. However, the converse is not true: programs linked against libxcrypt will not work with glibc's libcrypt. 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. Also, programs that use certain legacy APIs supplied by glibc's libcrypt (encrypt, encrypt_r, setkey, setkey_r, and fcrypt) cannot be compiled against libxcrypt.
While splitting things out of glibc is overall probably a good thing -- IMO the ecosystem has generally benefited from libtirpc -- in this case the proposed removal method concerns me:
* crypt(3)'s declaration is in unistd.h according to SUS. While a duplicate declaration has been in crypt.h for some time, standards-conforming software can reasonably rely on the former. The glibc crypt removal proposal included an outright removal of this declaration, along with _XOPEN_CRYPT, which would leave no way for libxcrypt to fulfill the standard. Instead, if at least GCC 5 can be assumed, they should be made conditional on __has_include(<crypt.h>).
* encrypt and setkey, while noted in the Future Directions as subject to future obsoletion or removal, is still not even officially obsolete in SUSv4. This plan seems to leave no way whatsoever to compile software which depends on these still-standardized calls.
* Has a rebuild of all libcrypt dependent packages been made with libxcrypt-devel, with a careful analysis of the resulting binaries to assure that they still have the exact same symbol dependencies on libcrypt as they do when built with glibc's? I'm concerned that e.g. configure test failures caused by re/moved declarations would cause features to be quietly disabled, or software to use their own bundled implementations instead.
On 11/09/2017 02:26 AM, Yaakov Selkowitz wrote:
On 2017-11-08 11:08, Björn 'besser82' Esser wrote:
since there has been some discussion in the last time about removing libcrypt from glibc in some time [1,2,3,4] and splitting it out into a separate project which can evolve quicker, I'd like to hear your oppinion about replacing glibc's libcrypt with libxcrypt [5] for Fedora 29 (or 30).
Is anyone besides us (committed to) using and contributing to libxcrypt?
Doesn't matter IMHO because libcrypt-nss is essentially our very own special snowflake, too.
While splitting things out of glibc is overall probably a good thing -- IMO the ecosystem has generally benefited from libtirpc -- in this case the proposed removal method concerns me:
- crypt(3)'s declaration is in unistd.h according to SUS. While a
duplicate declaration has been in crypt.h for some time, standards-conforming software can reasonably rely on the former. The glibc crypt removal proposal included an outright removal of this declaration, along with _XOPEN_CRYPT, which would leave no way for libxcrypt to fulfill the standard. Instead, if at least GCC 5 can be assumed, they should be made conditional on __has_include(<crypt.h>).
I think we can keep crypt at least in Fedora's <unistd.h>.
- encrypt and setkey, while noted in the Future Directions as subject to
future obsoletion or removal, is still not even officially obsolete in SUSv4. This plan seems to leave no way whatsoever to compile software which depends on these still-standardized calls.
But these calls are truly obsolete. We can't change them from 56-bit DES in glibc for backwards compatibility reasons, and applications really should not use DES anymore.
Thanks, Florian
Björn 'besser82' Esser wrote:
libxcrypt will be fully binary compatible with software linked against glibc's libcrypt and does not require any rebuilds. However, the converse is not true: programs linked against libxcrypt will not work with glibc's libcrypt. 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. Also, programs that use certain legacy APIs supplied by glibc's libcrypt (encrypt, encrypt_r, setkey, setkey_r, and fcrypt) cannot be compiled against libxcrypt.
I think it would make more sense to add the new APIs to glibc, without dropping existing APIs or changing the implementation of the remaining existing APIs.
Kevin Kofler
On 11/10/2017 02:21 PM, Kevin Kofler wrote:
Björn 'besser82' Esser wrote:
libxcrypt will be fully binary compatible with software linked against glibc's libcrypt and does not require any rebuilds. However, the converse is not true: programs linked against libxcrypt will not work with glibc's libcrypt. 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. Also, programs that use certain legacy APIs supplied by glibc's libcrypt (encrypt, encrypt_r, setkey, setkey_r, and fcrypt) cannot be compiled against libxcrypt.
I think it would make more sense to add the new APIs to glibc, without dropping existing APIs or changing the implementation of the remaining existing APIs.
I disagree, and I think so do all the people who work on glibc.
Florian
On 11/08/2017 06:08 PM, Björn 'besser82' Esser wrote:
Hello everyone,
since there has been some discussion in the last time about removing libcrypt from glibc in some time [1,2,3,4] and splitting it out into a separate project which can evolve quicker, I'd like to hear your oppinion about replacing glibc's libcrypt with libxcrypt [5] for Fedora 29 (or 30).
I'd prefer this to happen in Fedora 28 if at all possible.
Anyways, before this can happen, there is still some work to be done with libxcrypt, like adding a FIPS mode or FIPS compliance in a different way.
I think the best way to achieve that would be to contribute libxcrypt (its interfaces and its peculiar build process) to some FIPS-validated cryptographic libraries, so that the actual algorithms and FIPS mode logic could be reused from that library.
Otherwise, unless you have experience dealing with FIPS requirements and getting cryptographic libraries through validation, I strongly recommend not to work on this at all. If and when we need this downstream, we can contribute exactly what is needed according to the auditors back upstream. Personally, I do not have a way to know what the requirements would be in advance.
Thanks, Florian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Fri, 2017-11-10 at 14:39 +0100, Florian Weimer wrote:
On 11/08/2017 06:08 PM, Björn 'besser82' Esser wrote:
Hello everyone,
since there has been some discussion in the last time about removing libcrypt from glibc in some time [1,2,3,4] and splitting it out into a separate project which can evolve quicker, I'd like to hear your oppinion about replacing glibc's libcrypt with libxcrypt [5] for Fedora 29 (or 30).
I'd prefer this to happen in Fedora 28 if at all possible.
It is still possible to propose this as System-Wide change for F28 😉 - -- - -Igor Gnatenko
On Wed, 2017-11-08 at 18:08 +0100, Björn 'besser82' Esser wrote:
Hello everyone,
since there has been some discussion in the last time about removing libcrypt from glibc in some time [1,2,3,4] and splitting it out into a separate project which can evolve quicker, I'd like to hear your oppinion about replacing glibc's libcrypt with libxcrypt [5] for Fedora 29 (or 30).
A bit late, but thank you for driving that effort! It was time to move to a better crypt lib.
Anyways, before this can happen, there is still some work to be done with libxcrypt, like adding a FIPS mode or FIPS compliance in a different way.
I agree with Florian's comment on that.
regards, Nikos
Am Dienstag, den 13.03.2018, 10:11 +0100 schrieb Nikos Mavrogiannopoulos:
On Wed, 2017-11-08 at 18:08 +0100, Björn 'besser82' Esser wrote:
Hello everyone,
since there has been some discussion in the last time about removing libcrypt from glibc in some time [1,2,3,4] and splitting it out into a separate project which can evolve quicker, I'd like to hear your oppinion about replacing glibc's libcrypt with libxcrypt [5] for Fedora 29 (or 30).
A bit late, but thank you for driving that effort! It was time to move to a better crypt lib.
You're welcome! =)
Anyways, before this can happen, there is still some work to be done with libxcrypt, like adding a FIPS mode or FIPS compliance in a different way.
I agree with Florian's comment on that.
Well, my current plan for bringing FIPS compliance to libxcrypt would be to use the Linux Kernel Userspace Crypto API [1], which provides a large variety of hashing and crypto-algorithms using hardware capabilities, if supported / available on the system (software implementations otherwise).
To archive that, I consider using libkcapi [2] (we already have that in Fedora), which is written by Stephan Müller, who contributed most of the important parts from interfaced (libxcrypt would need to interface it anyways) Kernel Userspace API.
Using this implementation, we get the following benefits (and more) almost for free:
* FIPS approved / certified hashing and crypto-algorithms from a FIPS certified crypto-provider / device. * When the Kernel runs in FIPS mode, libxcrypt cannot use any non-FIPS algorithms and automatically behaves FIPS compliant. * libxcrypt doesn't need an extra FIPS audit / cert, since it is just a consumer of an already certified crypto-provider; hashing and crypto happens in the Kernel directly. * Less code to maintain, smaller binary size, architecture optimized implementations. * New, more secure, password hashing algorithms can be adapted as soon as the Kernel supports them.
What are your thoughts on this?
Cheers Björn
[1] https://www.kernel.org/doc/html/v4.15/crypto/userspace-if.html [2] http://www.chronox.de/libkcapi.html
On 03/31/2018 11:52 AM, Björn 'besser82' Esser wrote:
Am Dienstag, den 13.03.2018, 10:11 +0100 schrieb Nikos Mavrogiannopoulos:
On Wed, 2017-11-08 at 18:08 +0100, Björn 'besser82' Esser wrote:
Anyways, before this can happen, there is still some work to be done with libxcrypt, like adding a FIPS mode or FIPS compliance in a different way.
I agree with Florian's comment on that.
To clarify, my comments were:
“ I think the best way to achieve that would be to contribute libxcrypt (its interfaces and its peculiar build process) to some FIPS-validated cryptographic libraries, so that the actual algorithms and FIPS mode logic could be reused from that library.
Otherwise, unless you have experience dealing with FIPS requirements and getting cryptographic libraries through validation, I strongly recommend not to work on this at all. If and when we need this downstream, we can contribute exactly what is needed according to the auditors back upstream. Personally, I do not have a way to know what the requirements would be in advance. ”
Well, my current plan for bringing FIPS compliance to libxcrypt would be to use the Linux Kernel Userspace Crypto API [1], which provides a large variety of hashing and crypto-algorithms using hardware capabilities, if supported / available on the system (software implementations otherwise).
We aren't convinced that FIPS compliance for libxcrypt would be meaningful. With shadow passwords, password hashes do not cross a trust boundary, so that part of libxcrypt does not perform any cryptographic function.
Functions like encrypt_r, which have to be included for backwards compatibility, are unlikely to be implementable using AF_ALG because few kernels will have built-in single DES support. The AF_ALG interface of course uses file descriptors, so failures are a possibility, and functions like encrypt_r cannot report failure. We could terminate the process, but combined with the potential lack of a kernel implementation and the existence of applications which have not yet migrated their data away from single DES, I'm not sure if that's a good idea.
Thanks, Florian
-
Björn 'besser82' Esser -
Florian Weimer -
Igor Gnatenko -
Kevin Kofler -
Nikos Mavrogiannopoulos -
Yaakov Selkowitz