No edit summary |
(updated links to new packaging guidelines) |
||
| (14 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
= | == History == | ||
Over the years there were | Over the years there were attempts to consolidate cryptographic libraries in Fedora. The previous crypto consolidation effort is no longer pursued by the Fedora project. This page is retained as historical record, and to provide a simple guideline in selecting a crypto back-end when choice exists. | ||
[https://fedoraproject.org/wiki/FedoraCryptoConsolidationBackup Proceed to the historical record of the Crypto Consolidation Project]. | [https://fedoraproject.org/wiki/FedoraCryptoConsolidationBackup Proceed to the historical record of the Crypto Consolidation Project]. | ||
= Selecting a crypto library = | == Selecting a crypto library for Fedora == | ||
For applications which may provide multiple cryptographic back-ends, our recommendation is to utilize the back-end preferred by the upstream project/developer, as long as it does integrate with the Fedora system, that is, following [ | For applications which may provide multiple cryptographic back-ends, our recommendation is to utilize the back-end preferred by the upstream project/developer, as long as it does integrate with the Fedora system, that is, following [https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/ Crypto Policies], [[Features/SharedSystemCertificates]] and | ||
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Pkcs11Support/ PKCS#11 support]. | |||
The Fedora base image effort for docker and other containers, tries to ship only OpenSSL, so for applications targeting the minimal base image, OpenSSL is the recommended library. | |||
If still in doubt on which library to chose there are comparisons of TLS and crypto libraries available to assist in deciding. | If still in doubt on which library to chose there are comparisons of TLS and crypto libraries available to assist in deciding. | ||
| Line 22: | Line 15: | ||
* [https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries Wikipedia low-level crypto lib comparison] | * [https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries Wikipedia low-level crypto lib comparison] | ||
* [https://curl.haxx.se/docs/ssl-compared.html Comparison for curl] | * [https://curl.haxx.se/docs/ssl-compared.html Comparison for curl] | ||
== Selecting a crypto library for Red Hat Enterprise Linux == | |||
When considering integration with Red Hat Enterprise Linux, it is recommended to utilize a library from the base crypto backends, as they are guaranteed to pass all relevant crypto certifications (i.e., FIPS-140-2). The base crypto backends are (in no particular order): | |||
* [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] | |||
* [https://www.gnutls.org GnuTLS] | |||
* [https://www.openssl.org OpenSSL] | |||
* [https://gnupg.org/software/libgcrypt/index.html libgcrypt] | |||
Although nettle is available as a cryptographic back-end in Red Hat Enterprise Linux, it is not recommended to use directly, as it is considered an internal GnuTLS API and [https://access.redhat.com/articles/rhel-abi-compatibility there is no API or ABI stability guarantee]. | |||
* [https://access.redhat.com/articles/3655361 Link to RHEL8 crypto components] | |||
* [https://access.redhat.com/solutions/307523 Link to RHEL FIPS140-2 certificates] | |||
=== Selecting crypto backend for other languages === | |||
For other language bindings, we recommend utilizing wrappers over the base crypto libraries. Some examples: | |||
<!-- * Java: [http://openjdk.java.net/ the openjdk platform] wraps over NSS --> | |||
* Python: the [https://cryptography.io/ python-cryptography package] wraps over OpenSSL | |||
[[Category:Encryption]] | |||
Latest revision as of 10:12, 8 November 2019
History
Over the years there were attempts to consolidate cryptographic libraries in Fedora. The previous crypto consolidation effort is no longer pursued by the Fedora project. This page is retained as historical record, and to provide a simple guideline in selecting a crypto back-end when choice exists. Proceed to the historical record of the Crypto Consolidation Project.
Selecting a crypto library for Fedora
For applications which may provide multiple cryptographic back-ends, our recommendation is to utilize the back-end preferred by the upstream project/developer, as long as it does integrate with the Fedora system, that is, following Crypto Policies, Features/SharedSystemCertificates and PKCS#11 support.
The Fedora base image effort for docker and other containers, tries to ship only OpenSSL, so for applications targeting the minimal base image, OpenSSL is the recommended library.
If still in doubt on which library to chose there are comparisons of TLS and crypto libraries available to assist in deciding.
Selecting a crypto library for Red Hat Enterprise Linux
When considering integration with Red Hat Enterprise Linux, it is recommended to utilize a library from the base crypto backends, as they are guaranteed to pass all relevant crypto certifications (i.e., FIPS-140-2). The base crypto backends are (in no particular order):
Although nettle is available as a cryptographic back-end in Red Hat Enterprise Linux, it is not recommended to use directly, as it is considered an internal GnuTLS API and there is no API or ABI stability guarantee.
Selecting crypto backend for other languages
For other language bindings, we recommend utilizing wrappers over the base crypto libraries. Some examples:
- Python: the python-cryptography package wraps over OpenSSL