AES-cipher offload to engine in openssl-fips

Richard Levitte levitte at
Wed Feb 27 21:18:58 UTC 2019

On Wed, 27 Feb 2019 21:55:29 +0100,
Jakob Bohm via openssl-users wrote:
> On 27/02/2019 20:59, Salz, Rich via openssl-users wrote:
> > If you change a single line of code or do not build it EXACTLY as documented, you cannot claim to use the OpenSSL validation.
> >   
> I believe the context here is one I also mentioned in my comment on
> the 3.0 draft spec:
> - OpenSSL FIPS Module provides FIPS validated software implementations of
>   all/most of the permitted algorithms.
> - Engine provides FIPS validated (hardware?) implementations of one or
>   more implementations, under a separate FIPS validation, perhaps done
>   at the hardware level.
> - FIPS-capable OpenSSL (outside the FIPS boundary) is somehow made to use
>   both FIPS validated modules depending on various conditions (such as
>   algorithm availability).  FIPS-capable OpenSSL can be changed without
>   breaking the FIPS validation of the modules.
> - Overall application claims FIPS compliance as all crypto is done by
>   FIPS validated modules.

Side note: "FIPS-capable OpenSSL" isn't quite right.  Basically, if
libcrypto is capable of loading a dynamically loadable module, it's
"FIPS-capable", since it can load the FIPS provider module.

I see no reason why libcrypto should be able to load two
FIPS-validated modules (*) and use them both, all depending on what
algorithms and properties are desired (apart from the "fips"
property).  However, I've come to understand that those two modules
must not be made to cooperate, i.e. for a signing operation using
sha256WithRSAEncryption, it's not permitted for one module to do the
sha256 part and the other module to do the RSA calculations.


(*) an engine module is also a module...  all that actually makes it
an OpenSSL engine is two entry points, "bind_engine" and "v_check".

Richard Levitte         levitte at
OpenSSL Project

More information about the openssl-users mailing list