From Fedora Project Wiki

(Wiki gardening and fixed some spelling errors.)
Line 1: Line 1:
= Fedora Crypto Consolidation - History =
== 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.   
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 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 [[Packaging:CryptoPolicies]] and [[Features/SharedSystemCertificates]].  When considering integration with Red Hat Enterprise Linux, it is preferred to utilize one of the following crypto libraries (in no particular order).
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 [[Packaging:CryptoPolicies]] and [[Features/SharedSystemCertificates]].  When considering integration with Red Hat Enterprise Linux, it is preferred to utilize one of the following crypto libraries (in no particular order).
Line 13: Line 13:
* libgcrypt
* libgcrypt


All of the above libraries are FIPS140-2 certified. 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 guarrantee].
All of the above libraries are FIPS 140-2 certified. 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].
 
The Fedora base image effort for docker and other containers, tries to ship only OpenSSL, so for applications targetting the minimal base image, OpenSSL is the recommended library.


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.

Revision as of 17:36, 11 April 2017

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 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 Packaging:CryptoPolicies and Features/SharedSystemCertificates. When considering integration with Red Hat Enterprise Linux, it is preferred to utilize one of the following crypto libraries (in no particular order).

  • NSS
  • GnuTLS
  • OpenSSL
  • libgcrypt

All of the above libraries are FIPS 140-2 certified. 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.

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.