AES-cipher offload to engine in openssl-fips

Richard Levitte levitte at openssl.org
Thu Feb 28 08:15:02 UTC 2019


On Thu, 28 Feb 2019 00:17:13 +0100,
Salz, Rich wrote:
> 
> >    Huh?  From the design document, section "Example dynamic views of
>     algorithm selection", after the second diagram:
>     
>         An EVP_DigestSign* operation is more complicated because it
>         involves two algorithms: a signing algorithm, and a digest
>         algorithm. In general those two algorithms may come from different
>         providers or the same one. In the case of the FIPS module the
>         algorithms must both come from the same FIPS module provider. The
>         operation will fail if an attempt is made to do otherwise.
>   
> There are two options.  First, the application does the digest and
> sign as two separate things.

My memory is a foggy surrounding that scenario, so I might be wrong,
but I think it was argued that this was invalid use from a FIPS
perspective.  Now, we can't actually stop any application from doing
this, sure!  But...

> Second, the provider implementing digestSign has to be validated to
> use the other FIPS module.

Yes, and this is, as far as I remember, a "combined FIPS module" (I
don't remember the exact terminology, sorry) which is supposed to be
validated together and present itself to libcrypto as one provider,
not two.

However, what you wrote earlier was this:

> If the EVP API does the digesting with one module and then calls
> another module to do the RSA signing, that is okay.

That suggests to me that libcrypto could "magically" combine two
different FIPS providers, which would be none of the two options
mentioned above.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/


More information about the openssl-users mailing list