Re: AW: AES-cipher offload to engine in openssl-fips
On Thu, 28 Feb 2019 00:51:24 +0100, Dr. Matthias St. Pierre wrote: > > > > Uhm, I'm confused. I thought we were talking about 3.0? > > Well, the original post started at FIPS 2.0: > > > I am using openssl-fips-2.0.16 and openssl-1.0.2e. > https://mta.openssl.org/pipermail/openssl-users/2019-February/009919.html Yes, it did... and then evolved, as threads on the Internet often do (or for that matter, in physical life too). > But it seems like the discussion in the thread has drifted a little > towards the FIPS 3.0 future, which explains our mutual confusion. Yup :-) > For that reason it is even more important that we don't use legacy > terms like "FIPS capable" in the context of FIPS 3.0 and stick to > "FIPS Providers" (or whatever correct new terms are; I'm currently > not 100% up-to-date) instead. Cool, we agree then :-) "FIPS provider" is what we use within the team, or sometimes "FIPS provider module". They are synonymous, but the latter is more precise. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
AW: AES-cipher offload to engine in openssl-fips
> Uhm, I'm confused. I thought we were talking about 3.0? Well, the original post started at FIPS 2.0: > I am using openssl-fips-2.0.16 and openssl-1.0.2e. https://mta.openssl.org/pipermail/openssl-users/2019-February/009919.html But it seems like the discussion in the thread has drifted a little towards the FIPS 3.0 future, which explains our mutual confusion. For that reason it is even more important that we don't use legacy terms like "FIPS capable" in the context of FIPS 3.0 and stick to "FIPS Providers" (or whatever correct new terms are; I'm currently not 100% up-to-date) instead. Matthias
AW: AES-cipher offload to engine in openssl-fips
> -Ursprüngliche Nachricht- > > >I always understood "FIPS-capable OpenSSL" to refer specifically to an > > OpenSSL compiled with the options to incorporate the FIPS canister > > module, not just any OpenSSL build that might be used in FIPS compliant > > applications (as that would be any OpenSSL at all). > > > > Yes, that is historically correct. I don't believe the project uses > > the term "FIPS-capable OpenSSL" any more. Instead, the design and > > such talk about a FIPS module which OpenSSL can use. > > Correct. I disagree: The term "FIPS Capable OpenSSL" is a technical term from the OpenSSL FIPS 2.0 User Guide (https://www.openssl.org/docs/fips/UserGuide-2.0.pdf) and has a very clear and precise meaning: It refers to an OpenSSL 1.0.2 (or 1.0.1) library configured and built with `./configure fips ...` in order to integrate the FIPS Object Module. Until FIPS 3.0 has been released and FIPS 2.0 is history, we should stick to that definition and not confuse FIPS users by reinterpreting it or pretend that it is not used anymore or has a different meaning nowadays. Matthias -- You find the details in Sections 4.2.3 resp. 4.3.3 of https://www.openssl.org/docs/fips/UserGuide-2.0.pdf. 4.2.3 Building a FIPS Capable OpenSSL (Unix/Linux) 4.3.3 Building a FIPS Capable OpenSSL (Windows) Here a brief excerpt: Once the validated FIPS Object Module has been generated it is usually combined with an OpenSSL distribution in order to provide the standard OpenSSL API. Any 1.0.1 or 1.0.2 release can be used for this purpose. The commands ./config fips <...other options...> make <...options...> make install will build and install the new OpenSSL without overwriting the validated FIPS Object Module files. The FIPSDIR environment variable or the --withfipsdir command line option can be used to explicitly reference the location of the FIPS Object Module (fipscanister.o). The combination of the validated FIPS Object Module plus an OpenSSL distribution built in this way is referred to as a FIPS capable OpenSSL, as it can be used either as a drop-in replacement for a non-FIPS OpenSSL or for use in generating FIPS mode applications.
