Several days ago Matt Caswell, member of the development team of the OpenSSL project, announced the release of OpenSSL 3.0 which comes after 3 years of development, 17 alpha versions, 2 beta versions, more than 7500 confirmations and contributions from more than 350 different authors.
And it is that OpenSSL was fortunate to have had several full-time engineers who worked on OpenSSL 3.0, funded in various ways. Some companies have signed support contracts with the OpenSSL development team, which sponsored specific functions such as the FIPS module which had plans to restore its validation with OpenSSL 3.0, however, they encountered significant delays and, like the FIPS 140-2 tests ended in September 2021, OpenSSL finally decided to focus its efforts on FIPS 140-3 standards as well.
A key feature by OpenSSL 3.0 is the new FIPS module. The OpenSSL development team is testing the module and gathering the necessary documents for FIPS 140-2 validation. Using the new FIPS module in application development projects can be as easy as making some changes to the configuration file, although many applications will need to make other changes. The FIPS module man page provides information on how to use the FIPS module in your applications.
It should also be noted that since OpenSSL 3.0, OpenSSL has switched to Apache 2.0 license. The old "dual" licenses for OpenSSL and SSLeay still apply to earlier versions (1.1.1 and earlier). OpenSSL 3.0 is a major version and is not fully compatible with the previous version. Most applications that worked with OpenSSL 1.1.1 will continue to work unchanged and will simply need to be recompiled (possibly with many compilation warnings about using outdated APIs).
With OpenSSL 3.0, it is possible to specify, either programmatically or through a configuration file, which providers the user wants to use for a given application. OpenSSL 3.0 comes standard with 5 different providers. Over time, third parties may distribute additional providers that can be integrated with OpenSSL. All implementations of the algorithms available from vendors are accessible via "high-level" APIs (for example, functions with the prefix EVP). It cannot be accessed using "low-level" APIs.
One of the standard providers available is the FIPS provider which provides FIPS validated cryptographic algorithms. The FIPS provider is disabled by default and must be explicitly enabled during configuration using the enable-fips option. If enabled, the FIPS provider is created and installed in addition to other standard providers.
Using the new FIPS module in applications can be as easy as making some changes to the configuration file, although many applications will need to make other changes. Applications written to use the OpenSSL 3.0 FIPS module should not use any legacy APIs or features that bypass the FIPS module. This includes in particular:
- Low-level cryptographic APIs (it is recommended to use high-level APIs, such as EVP);
engines - all functions that create or modify custom methods (for example, EVP_MD_meth_new (), EVP_CIPHER_meth_new (), EVP_PKEY_meth_new (), RSA_meth_new (), EC_KEY_METHOD_new ()).
Moreover the OpenSSL cryptographic library (libcrypto) implements a wide range of cryptographic algorithms used in various Internet standards. Functionality includes symmetric encryption, public key cryptography, key agreement, certificate management, cryptographic hashing functions, cryptographic pseudo-random number generators, message authentication codes (MAC), key derivation functions (KDF), and various utilities . The services provided by this library are used to implement many other third party products and protocols. Here's an overview of the key libcrypto concepts below.
Cryptographic primitives such as the SHA256 hash or AES encryption are called "algorithms" in OpenSSL. Each algorithm can have multiple implementations available. For example, the RSA algorithm is available as a "default" implementation suitable for general use, and a "fips" implementation that has been validated against FIPS standards for situations where it is important. It is also possible for a third party to add additional implementations, for example in a hardware security module (HSM).
Finally if you are interested in knowing more about it, you can check the details In the following link.