As mentioned in a previous blog post, OpenSSL team members met with various representatives of the FIPS sponsor organisations back in September last year to discuss design and planning for the new FIPS module development project.

Since then there has been much design work taking place and we are now able to publish the draft design documentation. You can read about how we see the longer term architecture of OpenSSL changing in the future here and you can read about our specific plans for OpenSSL 3.0 (our next release which will include a FIPS validated module) here.

OpenSSL 3.0 is a major release and will be a significant change to the internal architecture of OpenSSL. We plan to keep impacts on existing end user applications to an absolute minimum with the intention that the vast majority of existing well-behaved applications will just need to be recompiled. No deprecated APIs will be removed in this release.

The biggest change will be the introduction of a new concept known as Providers. These can be seen as a replacement for the existing ENGINE interface and will enable much more flexibility for implementors. libcrypto gives applications access to a set of cryptographic algorithms, while different Providers may have different implementations of those algorithms.

Out-of-the-box OpenSSL will come with a set of Providers available. For example the “default” Provider will implement all of the most commonly used algorithms available in OpenSSL today. There will be a “legacy” Provider that implements legacy cryptographic algorithms and a FIPS Provider that implements FIPS validated algorithms. Existing engines will still work (after a recompile) and will be made available via both the old ENGINE APIs as well as a Provider compatibility layer.

The new design incorporates the FIPS module into main line OpenSSL. It will no longer be a separate download and support periods will also be aligned. It will of course be possible to build OpenSSL with or without the FIPS module depending on your own individual circumstances and requirements.

The FIPS module version number will be aligned with the main OpenSSL version number. OpenSSL 3.0.0 will incorporate the 3.0.0 FIPS module. Not every release of OpenSSL will necessarily lead to an update in the FIPS module version number so there may be “gaps”. For example OpenSSL 3.0.1 might still provide and work with the 3.0.0 module.

New APIs will be introduced to give applications greater flexibility in the selection of algorithm implementations. Of course support will be maintained for existing APIs so applications don’t need to use the new APIs if they don’t want to. For example applications will be able to set different algorithm selection criteria for different SSL_CTXs. This might be used to enforce selection of FIPS validated algorithms for one SSL_CTX, while allowing another SSL_CTX to use default implementations.

There is much still to be done to make this new OpenSSL design a reality. However with the publication of these design documents we are encouraged to see that pull requests are already starting to come in to make the necessary changes to the code. We expect the coming months to be very active amongst the development community as we head towards alpha and beta releases later on this year.