OpenSSLWiki - User contributions [en]

FIPS module 3.0

2016-10-31T14:52:52Z

Stevem: Added sponsorship info

The 3.0 FIPS module will be conceptually similar to the preceeding line of ''OpenSSL FIPS Object Module'' cryptographic modules. An extensive reworking of the internals is planned, to address some issues stemming from the historical origins and subsequent ad hoc evolution of previous modules.

== Sponsorship ==

As with the previous open source based FIPS 140 validation efforts, this validation would not be possible without financial sponsorship. The primary sponsor for this validation is SafeLogic, Inc. In addition to financial support SafeLogic is also collaborating on the validation work itself. SafeLogic welcomes participation by additional interested stakeholders and sponsors. Please direct any queries to:

:{| style="height=5em; border-spacing: 0px;"
|-
| Ray Potter
| ray@safelogic.com
|-
| SafeLogic Inc.
| https://www.safelogic.com/
|-
| 459 Hamilton Ave, Suite 306
| +1 844 436 2797
|-
| Palo Alto, CA 94301 USA
|
|}

== Technical Objectives ==

An initial rough draft of requirements and goals:

1) Keep it minimal and avoid any OpenSSL dependencies at all: i.e. make it fully usable as a stand alone crypto module (the 2.0 module is awkwardly usable without OpenSSL but its OpenSSL heritage shows).

2) Support compilation in various forms including as standalone ENGINE which is simply loaded into "normal" OpenSSL which then simply does all the FIPS weirdness automatically. Ideally a "FIPS capable" OpenSSL will no longer be required at all.

3) Overhaul the algorithm testing code to be much cleaner and modular than the hacky stuff we've lived with so far. Allow handling of huge test vector data files by "piping" data instead of having to store the full files on the target device (which can be problematic for embedded environments).

4) Consider feasibility of built in entropy sources so OpenSSL or the parent application/library aren't required to supply entropy.

5) A standalone minimal FIPS module tarball that contains only the code needed to build the contents of the crypto module (only what is inside the "cryptographic module boundary", in FIPS-speak). Omit the test suite software and much of the build-time software (strong precedent says that "incore" and "fipsld" can be omitted, for instance).

6) Ability to build out of the source tree.

7) FIPS 186-4 KeyGen.

8) SP 800-56A compliance (Self-tests per I.G. 9.6).
:: Diffie-Hellman full compliance with NIST SP 800-56A including CAVP algorithm testing.
:: Diffie-Hellman Known Answer Tests (KATs) that include shared secret KAT and KDF KAT.

9) SP 800-56B vendor affirmation (I.G. D.4).

10) SHA-3 and SHAKE.

11) Automatic execution of power-on self-tests (I.G. 9.5/9.10).

12) Any allowed efficiencies in power-on self-tests.

13) Alternate FIPS Approved modes of operation (turn self-tests and algorithms “off”).

14) Explore possibility of validating "stitched" algorithm implementations.

15) Consider any newly FIPS approved algorithms (e.g. new EC curves, Chacha/Poly)

Stakeholder requests:

a. RSA key wrapping as part of NIST SP 800-56B (also called KTS validation testing), if CAVS testing is available.

b. AES-GMAC compliance (I.G. A.5).

c. AES Key Wrap Compliance to NIST SP 800-38F.

d. PBKDF2 Suppport.

e. Format Preserving Encrypion Support (NIST SP 800-38G)

f. Addition of EC curve 25519

g. Improved entropy to meet NIST SP 800-90B.

h. Symmetric key wrap conformant to SP 800-38F

i. SP 800-135 KDFs

j. SP 800-108 KDFs

k. Addition of AES XPN

l. XTS-AES compliance to I.G. A.9

What we probably won't do:

1. Any "light" versions of the FIPS module (i.e fewer algorithm implementations). Each such variant would require a separate FIPS 140 validation which would be cost prohibitive.

2. The initial validation will only include a handful of popular platforms (e.g. Linux on x86). Each platform validation costs both time and money, with the risk of delaying the overall validation if we try to tackle too many in parallel before the validation is awarded (a lesson learned from the last open source based validation in 2012/2013). We will be able to queue up platform validations once the initial validation is formally submitted. However, checking that the new module builds and works for platforms of interest will be useful as platform portability code tweaks are usually minor.

3. Make any substantial addition or changes to the module once the initial development is substantially complete (another lesson learned from the 2.0 validation).

FIPS module 3.0

2016-09-27T13:34:55Z

Stevem: Added anti-goals

The 3.0 FIPS module will be conceptually similar to the preceeding line of ''OpenSSL FIPS Object Module'' cryptographic modules. An extensive reworking of the internals is planned, to address some issues stemming from the historical origins and subsequent ad hoc evolution of previous modules.

An initial rough draft of requirements and goals:

1) Keep it minimal and avoid any OpenSSL dependencies at all: i.e. make it fully usable as a stand alone crypto module (the 2.0 module is awkwardly usable without OpenSSL but its OpenSSL heritage shows).

2) Support compilation in various forms including as standalone ENGINE which is simply loaded into "normal" OpenSSL which then simply does all the FIPS weirdness automatically. Ideally a "FIPS capable" OpenSSL will no longer be required at all.

3) Overhaul the algorithm testing code to be much cleaner and modular than the hacky stuff we've lived with so far. Allow handling of huge test vector data files by "piping" data instead of having to store the full files on the target device (which can be problematic for embedded environments).

4) Consider feasibility of built in entropy sources so OpenSSL or the parent application/library aren't required to supply entropy.

5) A standalone minimal FIPS module tarball that contains only the code needed to build the contents of the crypto module (only what is inside the "cryptographic module boundary", in FIPS-speak). Omit the test suite software and much of the build-time software (strong precedent says that "incore" and "fipsld" can be omitted, for instance).

6) Ability to build out of the source tree.

7) FIPS 186-4 KeyGen.

8) SP 800-56A compliance (Self-tests per I.G. 9.6).
:: Diffie-Hellman full compliance with NIST SP 800-56A including CAVP algorithm testing.
:: Diffie-Hellman Known Answer Tests (KATs) that include shared secret KAT and KDF KAT.

9) SP 800-56B vendor affirmation (I.G. D.4).

10) SHA-3 and SHAKE.

11) Automatic execution of power-on self-tests (I.G. 9.5/9.10).

12) Any allowed efficiencies in power-on self-tests.

13) Alternate FIPS Approved modes of operation (turn self-tests and algorithms “off”).

14) Explore possibility of validating "stitched" algorithm implementations.

15) Consider any newly FIPS approved algorithms (e.g. new EC curves, Chacha/Poly)

Stakeholder requests:

a. RSA key wrapping as part of NIST SP 800-56B (also called KTS validation testing), if CAVS testing is available.

b. AES-GMAC compliance (I.G. A.5).

c. AES Key Wrap Compliance to NIST SP 800-38F.

d. PBKDF2 Suppport.

e. Format Preserving Encrypion Support (NIST SP 800-38G)

f. Addition of EC curve 25519

g. Improved entropy to meet NIST SP 800-90B.

h. Symmetric key wrap conformant to SP 800-38F

i. SP 800-135 KDFs

j. SP 800-108 KDFs

k. Addition of AES XPN

l. XTS-AES compliance to I.G. A.9

What we probably won't do:

1. Any "light" versions of the FIPS module (i.e fewer algorithm implementations). Each such variant would require a separate FIPS 140 validation which would be cost prohibitive.

2. The initial validation will only include a handful of popular platforms (e.g. Linux on x86). Each platform validation costs both time and money, with the risk of delaying the overall validation if we try to tackle too many in parallel before the validation is awarded (a lesson learned from the last open source based validation in 2012/2013). We will be able to queue up platform validations once the initial validation is formally submitted. However, checking that the new module builds and works for platforms of interest will be useful as platform portability code tweaks are usually minor.

3. Make any substantial addition or changes to the module once the initial development is substantially complete (another lesson learned from the 2.0 validation).

FIPS module 3.0

2016-09-27T13:20:50Z

Stevem: typo

FIPS module 2.0

2016-09-20T20:37:22Z

Stevem: Typo and tweak

The ''OpenSSL FIPS Object Module 2.0'' was first validated with FIPS 140-2 certificate [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 #1747] in mid-2013. This 2.0 FIPS module is compatible with OpenSSL releases 1.0.1 and 1.0.2, and not with any other releases.

Thanks to the [http://openssl.com/fips/hostage.html "hostage issue"] in 2015, two new "clone" validations (known as "Alternative Scenario 1A" validations, also referred to as "re-brand" validations by some test labs) were obtained for the same module. The "RE" validation, [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2473 #2473], was intended to be identical to #1747 while allowing the addition of new platforms. The "SE" validation, [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2398 #2398], was intended for the addition of platforms requiring source code mods and thus new revisions to the module tarball. The #1747 and #2473 validations will forever remain at revision 2.0.10, while new revisions will be added to #2398 (which is at 2.0.13 as of September 2016).

Note that although the paperwork for the two clone validations #2398 and #2473 was submitted at the same time, and the two sets of paperwork were precisely identical other than the respective references to "RE" versus "SE" in the module names, they were approved at different times (July and November) with different editorial modifications required by the CMVP for the Security Policy documents. Such inconsistencies are common with FIPS 140-2 validations; the outcome from one validation effort is not necessarily predictive of what will happen for subsequent similar (or even identical) attempts.

In addition to the three validations of the ''OpenSSL FIPS Object Module 2.0'' obtained directly by OpenSSL, some third party vendors have obtained additional "re-brand" validations of the same cryptographic module:

:: [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2676 #2676], Cohesity OpenSSL FIPS Object Module
:: [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2631 #2631], Intel OpenSSL FIPS Object Module
:: [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2575 #2575], Cellcrypt Secure Core 3 FIPS 140-2 Module
:: [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2454 #2454], LogRhythm FIPS Object Module Version 6.3.4
:: [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2454 #2422], Nimble Storage OpenSSL FIPS Object Module

Note that while these clone validations have re-branded proprietary module names, they reference the original ''OpenSSL FIPS Object Module 2.0'' tarballs which are available under the open source OpenSSL license, and hence these validations can be used and cited by anyone.

A list of formally tested platforms ("Operational Environments") is associated with each validation. Collectively there are over two hundred unique platforms listed across all the ''OpenSSL FIPS Object Module 2.0'' validations:

{| class="wikitable"
|+Unique platforms across all ''OpenSSL FIPS Object Module 2.0'' validations as of 2016-09
|-
|AcanOS 1.0 running on Feroceon 88FR131 (ARMv5) (gcc Compiler Version 4.5.3)
|-
|AcanOS 1.0 running on Intel Core i7-3612QE (x86) with AES-NI (gcc Compiler Version 4.6.2)
|-
|AcanOS 1.0 running on Intel Core i7-3612QE (x86) without AES-NI (gcc Compiler Version 4.6.2)
|-
|AIX 6.1 32-bit running on IBM POWER 7 (PPC) (IBM XL C/C++ for AIX Compiler Version V13.1)
|-
|AIX 6.1 32-bit running on IBM POWER 7 (PPC) with optimizations (IBM XL C/C++ for AIX Compiler Version V10.1)
|-
|AIX 6.1 64-bit running on IBM POWER 7 (PPC) (IBM XL C/C++ for AIX Compiler Version V13.1)
|-
|AIX 6.1 64-bit running on IBM POWER 7 (PPC) with optimizations (IBM XL C/C++ for AIX Compiler Version V10.1)
|-
|AIX 7.1 32-bit running on IBM POWER 7 (PPC) (IBM XL C/C++ for AIX Compiler Version V13.1)
|-
|AIX 7.1 64-bit running on IBM POWER 7 (PPC) (IBM XL C/C++ for AIX Compiler Version V13.1)
|-
|Android 2.2 (gcc Compiler Version 4.4.0)
|-
|Android 2.2 running on OMAP 3530 (ARMv7) with NEON (gcc Compiler Version 4.1.0)
|-
|Android 2.2 running on Qualcomm QSD8250 (ARMv7) with NEON (gcc Compiler Version 4.4.0)
|-
|Android 2.2 running on Qualcomm QSD8250 (ARMv7) without NEON (gcc Compiler Version 4.4.0)
|-
|Android 3.0 (gcc Compiler Version 4.4.0)
|-
|Android 3.0 running on NVIDIA Tegra 250 T20 (ARMv7) (gcc Compiler Version 4.4.0)
|-
|Android 4.0 (gcc Compiler Version 4.4.3)
|-
|Android 4.0 running on NVIDIA Tegra 250 T20 (ARMv7) (gcc Compiler Version 4.4.3)
|-
|Android 4.0 running on Qualcomm Snapdragon APQ8060 (ARMv7) with NEON (gcc compiler Version 4.4.3)
|-
|Android 4.0 running on TI OMAP 3 (ARMv7) with NEON (gcc Compiler Version 4.4.3)
|-
|Android 4.1 running on TI DM3730 (ARMv7) (gcc Compiler Version 4.6)
|-
|Android 4.1 running on TI DM3730 (ARMv7) with NEON (gcc Complier Version 4.6)
|-
|Android 4.1 running on TI DM3730 (ARMv7) without NEON (gcc Compiler Version 4.6)
|-
|Android 4.2 running on Nvidia Tegra 3 (ARMv7) (gcc Compiler Version 4.6)
|-
|Android 4.2 running on Nvidia Tegra 3 (ARMv7) with Neon (gcc Compiler Version 4.6)
|-
|Android 4.2 running on Nvidia Tegra 3 (ARMv7) with NEON (gcc Compiler Version 4.6)
|-
|Android 4.2 running on Nvidia Tegra 3 (ARMv7) without NEON (gcc Compiler Version 4.6)
|-
|Android 5.0 32-bit running on Qualcomm APQ8084 (ARMv7) with NEON (gcc Compiler Version 4.9)
|-
|Android 5.0 32-bit running on Qualcomm APQ8084 (ARMv7) without NEON (gcc Compiler Version 4.9)
|-
|Android 5.0 64-bit running on SAMSUNG Exynos7420 (ARMv8) with NEON and Crypto Extensions (gcc Compiler Version 4.9)
|-
|Android 5.0 64-bit running on SAMSUNG Exynos7420 (ARMv8) without NEON and Crypto Extensions (gcc Compiler Version 4.9)
|-
|Apple iOS 5.0 running on ARM Cortex A8 (ARMv7) with NEON (gcc Compiler Version 4.2.1)
|-
|Apple iOS 5.1 (gcc Compiler Version 4.2.1)
|-
|Apple iOS 5.1 running on ARMv7 (gcc Compiler Version 4.2.1)
|-
|Apple iOS 6.1 running on Apple A6X SoC (ARMv7s) (gcc Compiler Version 4.2.1)
|-
|Apple iOS 7.1 64-bit running on Apple A7 (ARMv8) with NEON (clang Compiler Version 5.1)
|-
|Apple iOS 7.1 64- bit running on Apple A7 (ARMv8) without NEON (clang Compiler Version 5.1)
|-
|Apple OS X 10.7 running on Intel Core i7-3615QM (Apple LLVM version 4.2)
|-
|ArbOS 5.3 running on Xeon E5645 (x86) with AES-NI (gcc Compiler Version 4.1.2)
|-
|ArbOS 5.3 running on Xeon E5645 (x86) without AES-NI (gcc Compiler Version 4.1.2)
|-
|CascadeOS 6.1 (32 bit) (gcc Compiler Version 4.4.5)
|-
|CascadeOS 6.1 (32 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.4.5)
|-
|CascadeOS 6.1 (64 bit) (gcc Compiler Version 4.4.5)
|-
|CascadeOS 6.1 (64 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.4.5)
|-
|CentOS 5.6 64-bit running on Intel Xeon E5-2620v3 (gcc Compiler Version 4.1.2)
|-
|CentOS 5.6 64-bit running on Intel Xeon E5-2690v3 (gcc Compiler Version 4.1.2)
|-
|DataGravity Discovery Series OS V2.0 running on Intel Xeon E5-2420 (x86) with AES-NI (gcc Compiler Version 4.7.2)
|-
|DataGravity Discovery Series OS V2.0 running on Intel Xeon E5-2420 (x86) without AES-NI (gcc Compiler Version 4.7.2)
|-
|DSP Media Framework 1.4 running on TI C64x+ (TMS320C6x C/C++ Compiler v6.0.13)
|-
|DSP Media Framework 1.4 (TMS320C6x C/C++ Compiler v6.0.13)
|-
|eCos 3 running on Freescale i.MX27 926ejs (ARMv5TEJ) (gcc Compiler Version 4.3.2)
|-
|Fedora 14 running on Intel Core i5 with AES-NI (gcc Compiler Version 4.5.1)
|-
|FreeBSD 10.0 running on Xeon E5- 2430L (x86) with AES-NI (clang Compiler Version 3.3)
|-
|FreeBSD 10.0 running on Xeon E5-2430L (x86) with AES-NI (clang Compiler Version 3.3)
|-
|FreeBSD 10.0 running on Xeon E5-2430L (x86) without AES-NI (clang Compiler Version 3.3)
|-
|FreeBSD 10.2 running on Intel Xeon E5-2430L (x86) with AES-NI (clang Compiler Version 3.4.1)
|-
|FreeBSD 10.2 running on Intel Xeon E5-2430L (x86) without AES-NI (clang Compiler Version 3.4.1)
|-
|FreeBSD 8.4 running on Intel Xeon E5440 (x86) 32-bit (gcc Compiler Version 4.2.1)
|-
|FreeBSD 8.4 running on Intel Xeon E5440 (x86) without AES-NI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 8.4 running on Intel Xeon E5440 (x86) without AESNI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 9.1 running on Xeon E5-2430L (x86) with AES-NI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 9.1 running on Xeon E5-2430L (x86) without AES-NI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 9.1 running on Xeon E5-2430L (x86) without AESNI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 9.2 running on Xeon E5-2430L (x86) with AES-NI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 9.2 running on Xeon E5-2430L (x86) without AES-NI (gcc Compiler Version 4.2.1)
|-
|HP-UX 11i (32 bit) (HP C/aC++ B3910B)
|-
|HP-UX 11i (32 bit) running on Intel Itanium 2 (HP C/aC++ B3910B)
|-
|HP-UX 11i (64 bit) (HP C/aC++ B3910B)
|-
|HP-UX 11i (64 bit) running on Intel Itanium 2 (HP C/aC++ B3910B)
|-
|iOS 6.0 running on Apple A5 / ARM Cortex-A9 (ARMv7) with NEON (gcc Compiler Version 4.2.1)
|-
|iOS 6.0 running on Apple A5 / ARM Cortex-A9 (ARMv7) without NEON (gcc Compiler Version 4.2.1)
|-
|iOS 8.1 32bit running on Apple A7 (ARMv8) with NEON (clang Compiler Version 600.0.56)
|-
|iOS 8.1 32-bit running on Apple A7 (ARMv8) with NEON (clang Compiler Version 600.0.56)
|-
|iOS 8.1 32bit running on Apple A7 (ARMv8) without NEON (clang Compiler Version 600.0.56)
|-
|iOS 8.1 32-bit running on Apple A7 (ARMv8) without NEON (clang Compiler Version 600.0.56)
|-
|iOS 8.1 64bit running on Apple A7 (ARMv8) with NEON and Crypto Extensions (clang Compiler Version 600.0.56)
|-
|iOS 8.1 64-bit running on Apple A7 (ARMv8) with NEON and Crypto Extensions (clang Compiler Version 600.0.56)
|-
|iOS 8.1 64bit running on Apple A7 (ARMv8) without NEON and Crypto Extensions (clang Compiler Version 600.0.56)
|-
|iOS 8.1 64-bit running on Apple A7 (ARMv8) without NEON and Crypto Extensions (clang Compiler Version 600.0.56)
|-
|iOS 8.1 64-bit running on Apple A7 (ARMv8) without NEON and Crypto Extensions (clang Compilerv Version 600.0.56)
|-
|Linux 2.6.27 (gcc Compiler Version 4.2.4)
|-
|Linux 2.6.27 running on PowerPC e300c3 (gcc Compiler Version 4.2.4)
|-
|Linux 2.6.32 (gcc Compiler Version 4.3.2)
|-
|Linux 2.6.32 running on TI AM3703CBP (ARMv7) (gcc Compiler Version 4.3.2)
|-
|Linux 2.6.33 (gcc Compiler Version 4.1.0)
|-
|Linux 2.6.33 running on PowerPC32 e300 (gcc Compiler Version 4.1.0)
|-
|Linux 2.6 (gcc Compiler Version 4.1.0)
|-
|Linux 2.6 (gcc Compiler Version 4.3.2)
|-
|Linux 2.6 running on a Nimble Storage CS300 with AES-NI
|-
|Linux 2.6 running on a Nimble Storage CS500 with AES-NI
|-
|Linux 2.6 running on a Nimble Storage CS700 with AES-NI
|-
|Linux 2.6 running on Broadcom BCM11107 (ARMv6) (gcc Compiler Version 4.3.2)
|-
|Linux 2.6 running on Freescale e500v2 (PPC) (gcc Compiler Version 4.4.1)
|-
|Linux 2.6 running on Freescale PowerPCe500 (gcc Compiler Version 4.1.0)
|-
|Linux 2.6 running on TI TMS320DM6446 (ARMv4) (gcc Compiler Version 4.3.2)
|-
|Linux 3.10 32-bit running on Intel Atom E3845 (x86) with AES-NI (gcc Compiler Version 4.8.1)
|-
|Linux 3.10 32-bit running on Intel Atom E3845 (x86) without AES-NI (gcc Compiler Version 4.8.1)
|-
|Linux 3.10 on VMware ESXi 6.00 running on Intel Xeon with AES-NI (gcc Compiler Version 4.8.3)
|-
|Linux 3.10 on Vmware ESXi 6.00 running on Intel Xeon without AES-NI (gcc Compiler Version 4.8.3)
|-
|Linux 3.10 running on Intel Xeon with AES-NI (gcc Compiler Version 4.8.3)
|-
|Linux 3.10 running on Intel Xeon without AES-NI (gcc Compiler Version 4.8.3)
|-
|Linux 3.4 64-bit under Citrix XenServer running on Intel Xeon E5-2430L (x86) without AES-NI
|-
|Linux 3.4 under Citrix XenServer 6.2 running on Intel Xeon E5-2430L with AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.4 under Citrix XenServer 6.2 running on Intel Xeon E5-2430L without AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.4 under Microsoft Windows 2012 Hyper-V running on Intel Xeon E5-2430L with AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.4 under Microsoft Windows 2012 Hyper-V running on Intel Xeon E5-2430L with AES-NI (gcc Compiler Version 4.8.0)2
|-
|Linux 3.4 under Microsoft Windows 2012 Hyper-V running on Intel Xeon E5-2430L without AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.4 under Vmware ESXi 5.1 running on Intel Xeon E5-2430L with AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.4 under Vmware ESXi 5.1 running on Intel Xeon E5-2430L without AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.8 running on ARM926 (ARMv5TEJ) (gcc Compiler Version 4.7.3)
|-
|Linux ORACLESP 2.6 running on ASPEED AST-Series (ARMv5) (gcc Compiler Version 4.4.5)
|-
|Linux ORACLESP 2.6 running on Emulex PILOT3 (ARMv5) (gcc Compiler Version 4.4.5)
|-
|Microsoft Windows 7 (32 bit) (Microsoft 32 bit C/C++ Optimizing Compiler Version 16.00)
|-
|Microsoft Windows 7 (32 bit) running on Intel Celeron (Microsoft 32 bit C/C++ Optimizing Compiler Version 16.00)
|-
|Microsoft Windows 7 (64 bit) (Microsoft C/C++ Optimizing Compiler Version 16.00)
|-
|Microsoft Windows 7 (64 bit) running on Intel Pentium 4 (Microsoft C/C++ Optimizing Compiler Version 16.00)
|-
|Microsoft Windows 7 running on Intel Core i5- 2430M (64-bit) with AES-NI (Microsoft ® C/C++ Optimizing Compiler Version 16.00 for x64)
|-
|Microsoft Windows 7 running on Intel Core i5-2430M (64-bit) with AES-NI (Microsoft « C/C++ Optimizing Compiler Version 16.00 for x64)
|-
|Microsoft Windows CE 5.0 (Microsoft C/C++ Optimizing Compiler Version 13.10 for ARM)
|-
|Microsoft Windows CE 5.0 running on ARMv7 (Microsoft C/C++ Optimizing Compiler Version 13.10 for ARM)
|-
|Microsoft Windows CE 6.0 (Microsoft C/C++ Optimizing Compiler Version 15.00 for ARM)
|-
|Microsoft Windows CE 6.0 running on ARMv5TEJ (Microsoft C/C++ Optimizing Compiler Version 15.00 for ARM)
|-
|Microsoft Windows Server 2008 R2 running on an Intel Xeon E5-2420 (x64) (Microsoft 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86)
|-
|NetBSD 5.1 (gcc Compiler Version 4.1.3)
|-
|NetBSD 5.1 running on Intel Xeon 5500 (gcc Compiler Version 4.1.3)
|-
|NetBSD 5.1 running on PowerPCe500 (gcc Compiler Version 4.1.3)
|-
|OpenWRT 2.6 running on MIPS 24Kc (gcc Compiler Version 4.6.3)
|-
|Oracle Linux 5 (64 bit) (gcc Compiler Version 4.1.2)
|-
|Oracle Linux 5 (64 bit) running on Intel Xeon 5675 (gcc Compiler Version 4.1.2)
|-
|Oracle Linux 5 running on Intel Xeon 5675 with AES-NI (gcc Compiler Version 4.1.2)
|-
|Oracle Linux 6 (gcc Compiler Version 4.4.6)
|-
|Oracle Linux 6 running on Intel Xeon 5675 with AES-NI (gcc Compiler Version 4.4.6)
|-
|Oracle Linux 6 running on Intel Xeon 5675 without AES-NI (gcc Compiler Version 4.4.6)
|-
|Oracle Solaris 10 (32 bit) (gcc Compiler Version 3.4.3)
|-
|Oracle Solaris 10 (32 bit) running on SPARC-T3 (SPARCv9) (gcc Compiler Version3.4.3)
|-
|Oracle Solaris 10 (64 bit) (gcc Compiler Version 3.4.3)
|-
|Oracle Solaris 10 (64 bit) running on SPARC-T3 (SPARCv9) (gcc Compiler Version 3.4.3)
|-
|Oracle Solaris 11(32 bit) (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 (32 bit) running on Intel Xeon 5675 (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 (32 bit) running on SPARC-T3 (SPARCv9) (Sun C Version 5.12)
|-
|Oracle Solaris 11 (32 bit) (Sun C Version 5.12)
|-
|Oracle Solaris 11 (64 bit) (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 (64 bit) running on Intel Xeon 5675 (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 (64 bit) running on SPARC-T3 (SPARCv9) (Sun C Version 5.12)
|-
|Oracle Solaris 11 (64 bit) (Sun C Version 5.12)
|-
|Oracle Solaris 11 running on Intel Xeon 5675 with AES-NI (32 bit) (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 running on Intel Xeon 5675 with AESNI (32 bit) (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 running on Intel Xeon 5675 with AES-NI (64 bit) (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 running on Intel Xeon 5675 with AESNI (64 bit) (gcc Compiler Version 4.5.2)
|-
|PexOS 1.0 under vSphere ESXi 5.1 running on Intel Xeon E52430L with AES-NI (gcc Compiler Version 4.6.3)3
|-
|PexOS 1.0 under vSphere ESXi 5.1 running on Intel Xeon E52430L without AES-NI (gcc Compiler Version 4.6.3)
|-
|QNX 6.4 running on Freescale i.MX25 (ARMv4) (gcc Compiler Version 4.3.3)
|-
|QNX 6.5 running on Freescale i.MX25 (ARMv4) (gcc Compiler Version 4.3.3)
|-
|TS-Linux 2.4 running on Arm920Tid (ARMv4) (gcc Compiler Version 4.3.2)
|-
|TS-Linux 2.4 running on Arm920Tid (ARMv4) (gcc Compiler Version 4.3.2)4
|-
|Ubuntu 10.04 (32 bit) (gcc Compiler Version 4.1.3)
|-
|Ubuntu 10.04 (32 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.1.3)
|-
|Ubuntu 10.04 (64 bit) (gcc Compiler Version 4.1.3)
|-
|Ubuntu 10.04 (64 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.1.3)
|-
|Ubuntu 10.04 running on Intel Core i5 with AES-NI (32 bit) (gcc Compiler Version 4.1.3)
|-
|Ubuntu 10.04 running on Intel Pentium T4200 (gcc Compiler Version 4.1.3)
|-
|Ubuntu 12.04 running on Intel Xeon E5-2430L (x86) with AES-NI (gcc Compiler Version 4.6.3)
|-
|Ubuntu 12.04 running on Intel Xeon E5-2430L (x86) without AES-NI (gcc Compiler Version 4.6.3)
|-
|Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) (gcc Compiler Version 4.7.3)
|-
|Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) with NEON (gcc Compiler Version 4.7.3)
|-
|Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) without NEON (gcc Compiler Version 4.7.3)
|-
|uCLinux 0.9.29 (gcc Compiler Version 4.2.1)
|-
|uCLinux 0.9.29 running on ARM 922T (ARMv4) (gcc Compiler Version 4.2.1)
|-
|Vmware Horizon Workspace 1.5 under Vmware ESXi 5.0 running on Intel Xeon E3-1220 (x86) with AES-NI (gcc Compiler Version 4.5.1)1
|-
|Vmware Horizon Workspace 1.5 under Vmware ESXi 5.0 running on Intel Xeon E3-1220 (x86) without AES-NI (gcc Compiler Version 4.5.1)
|-
|Vmware Horizon Workspace 2.1 under vSphere ESXi 5.5 running on Intel Xeon E3-1220 (x86) with AES-NI (gcc Compiler Version 4.5.1)
|-
|Vmware Horizon Workspace 2.1 under vSphere ESXi 5.5 running on Intel Xeon E3-1220 (x86) with AESNI (gcc Compiler Version 4.5.1)
|-
|Vmware Horizon Workspace 2.1 under vSphere ESXi 5.5 running on Intel Xeon E3-1220 (x86) without AES-NI (gcc Compiler Version 4.5.1)
|-
|VxWorks 6.7 running on Intel Core 2 Duo (x86) (gcc Compiler Version 4.1.2)
|-
|VxWorks 6.8 (gcc Compiler Version 4.1.2)
|-
|VxWorks 6.8 running on TI TNETV1050 (MIPS) (gcc Compiler Version 4.1.2)
|-
|VxWorks 6.9 running on Freescale P2020 (PPC) (gcc Compiler Version 4.3.3)
|-
|Windows Embedded Compact 7 running on Freescale i.MX53xA (ARMv7) with NEON (Microsoft C/C++ Optimizing Compiler Version 15.00.20720)
|-
|Windows Embedded Compact 7 running on Freescale i.MX53xD (ARMv7) with NEON (Microsoft C/C++ Optimizing Compiler Version 15.00.20720)
|}

FIPS module 2.0

2016-09-20T19:49:37Z

Stevem: fix typo

The ''OpenSSL FIPS Object Module 2.0'' was first validated with FIPS 140-2 certificate [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 #1747] in mid-2013. This 2.0 FIPS module is compatible with OpenSSL releases 1.0.1 and 1.0.2, and not with any other releases.

Thanks to the [http://openssl.com/fips/hostage.html "hostage issue"] in 2015, two new "clone" validations (known as "Alternative Scenario 1A" validations, also referred to as "re-brand" validations by some test labs) were obtained for the same module. The "RE" validation, [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2473 #2473], was intended to be identical to #1747 while allowing the addition of new platforms. The "SE" validation, [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2398 #2398], was intended for the addition of platforms requiring source code mods and thus new revisions to the module tarball. The #1747 and #2473 validations will forever remain at revision 2.0.10, while new revisions will be added to #2398 (which is at 2.0.13 as of September 2016).

Note that although the paperwork for the two clone validations #2398 and #2473 was submitted at the same time, and the two sets of paperwork were precisely identical other than the respective references to "RE" versus "SE" in the module names, they were approved at different times (July and November) with different editorial modifications required by the CMVP for the Security Policy documents. Such inconsistencies are common with FIPS 140-2 validations; the outcome from one validation effort is not necessarily predictive of what will happen for subsequent similar (or even identical) attempts.

In addition to the three validations of the ''OpenSSL FIPS Object Module 2.0'' obtained directly by OpenSSL, some third party vendors have obtained additional "re-brand" validations:

:: [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2676 #2676], Cohesity OpenSSL FIPS Object Module
:: [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2631 #2631], Intel OpenSSL FIPS Object Module
:: [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2575 #2575], Cellcrypt Secure Core 3 FIPS 140-2 Module
:: [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2454 #2454], LogRhythm FIPS Object Module Version 6.3.4
:: [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2454 #2422], Nimble Storage OpenSSL FIPS Object Module

Noe that while these clone validations have re-branded proprietary module names, they reference the original ''OpenSSL FIPS Object Module 2.0'' tarballs which are available under the open source OpenSSL license, and hence these validations can be used and cited by anyone.

A list of formally tested platforms ("Operational Environments") is associated with each validation. Collectively there are over two hundred unique platforms listed across all the ''OpenSSL FIPS Object Module 2.0'' validations:

{| class="wikitable"
|+Unique platforms across all ''OpenSSL FIPS Object Module 2.0'' validations as of 2016-09
|-
|AcanOS 1.0 running on Feroceon 88FR131 (ARMv5) (gcc Compiler Version 4.5.3)
|-
|AcanOS 1.0 running on Intel Core i7-3612QE (x86) with AES-NI (gcc Compiler Version 4.6.2)
|-
|AcanOS 1.0 running on Intel Core i7-3612QE (x86) without AES-NI (gcc Compiler Version 4.6.2)
|-
|AIX 6.1 32-bit running on IBM POWER 7 (PPC) (IBM XL C/C++ for AIX Compiler Version V13.1)
|-
|AIX 6.1 32-bit running on IBM POWER 7 (PPC) with optimizations (IBM XL C/C++ for AIX Compiler Version V10.1)
|-
|AIX 6.1 64-bit running on IBM POWER 7 (PPC) (IBM XL C/C++ for AIX Compiler Version V13.1)
|-
|AIX 6.1 64-bit running on IBM POWER 7 (PPC) with optimizations (IBM XL C/C++ for AIX Compiler Version V10.1)
|-
|AIX 7.1 32-bit running on IBM POWER 7 (PPC) (IBM XL C/C++ for AIX Compiler Version V13.1)
|-
|AIX 7.1 64-bit running on IBM POWER 7 (PPC) (IBM XL C/C++ for AIX Compiler Version V13.1)
|-
|Android 2.2 (gcc Compiler Version 4.4.0)
|-
|Android 2.2 running on OMAP 3530 (ARMv7) with NEON (gcc Compiler Version 4.1.0)
|-
|Android 2.2 running on Qualcomm QSD8250 (ARMv7) with NEON (gcc Compiler Version 4.4.0)
|-
|Android 2.2 running on Qualcomm QSD8250 (ARMv7) without NEON (gcc Compiler Version 4.4.0)
|-
|Android 3.0 (gcc Compiler Version 4.4.0)
|-
|Android 3.0 running on NVIDIA Tegra 250 T20 (ARMv7) (gcc Compiler Version 4.4.0)
|-
|Android 4.0 (gcc Compiler Version 4.4.3)
|-
|Android 4.0 running on NVIDIA Tegra 250 T20 (ARMv7) (gcc Compiler Version 4.4.3)
|-
|Android 4.0 running on Qualcomm Snapdragon APQ8060 (ARMv7) with NEON (gcc compiler Version 4.4.3)
|-
|Android 4.0 running on TI OMAP 3 (ARMv7) with NEON (gcc Compiler Version 4.4.3)
|-
|Android 4.1 running on TI DM3730 (ARMv7) (gcc Compiler Version 4.6)
|-
|Android 4.1 running on TI DM3730 (ARMv7) with NEON (gcc Complier Version 4.6)
|-
|Android 4.1 running on TI DM3730 (ARMv7) without NEON (gcc Compiler Version 4.6)
|-
|Android 4.2 running on Nvidia Tegra 3 (ARMv7) (gcc Compiler Version 4.6)
|-
|Android 4.2 running on Nvidia Tegra 3 (ARMv7) with Neon (gcc Compiler Version 4.6)
|-
|Android 4.2 running on Nvidia Tegra 3 (ARMv7) with NEON (gcc Compiler Version 4.6)
|-
|Android 4.2 running on Nvidia Tegra 3 (ARMv7) without NEON (gcc Compiler Version 4.6)
|-
|Android 5.0 32-bit running on Qualcomm APQ8084 (ARMv7) with NEON (gcc Compiler Version 4.9)
|-
|Android 5.0 32-bit running on Qualcomm APQ8084 (ARMv7) without NEON (gcc Compiler Version 4.9)
|-
|Android 5.0 64-bit running on SAMSUNG Exynos7420 (ARMv8) with NEON and Crypto Extensions (gcc Compiler Version 4.9)
|-
|Android 5.0 64-bit running on SAMSUNG Exynos7420 (ARMv8) without NEON and Crypto Extensions (gcc Compiler Version 4.9)
|-
|Apple iOS 5.0 running on ARM Cortex A8 (ARMv7) with NEON (gcc Compiler Version 4.2.1)
|-
|Apple iOS 5.1 (gcc Compiler Version 4.2.1)
|-
|Apple iOS 5.1 running on ARMv7 (gcc Compiler Version 4.2.1)
|-
|Apple iOS 6.1 running on Apple A6X SoC (ARMv7s) (gcc Compiler Version 4.2.1)
|-
|Apple iOS 7.1 64-bit running on Apple A7 (ARMv8) with NEON (clang Compiler Version 5.1)
|-
|Apple iOS 7.1 64- bit running on Apple A7 (ARMv8) without NEON (clang Compiler Version 5.1)
|-
|Apple OS X 10.7 running on Intel Core i7-3615QM (Apple LLVM version 4.2)
|-
|ArbOS 5.3 running on Xeon E5645 (x86) with AES-NI (gcc Compiler Version 4.1.2)
|-
|ArbOS 5.3 running on Xeon E5645 (x86) without AES-NI (gcc Compiler Version 4.1.2)
|-
|CascadeOS 6.1 (32 bit) (gcc Compiler Version 4.4.5)
|-
|CascadeOS 6.1 (32 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.4.5)
|-
|CascadeOS 6.1 (64 bit) (gcc Compiler Version 4.4.5)
|-
|CascadeOS 6.1 (64 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.4.5)
|-
|CentOS 5.6 64-bit running on Intel Xeon E5-2620v3 (gcc Compiler Version 4.1.2)
|-
|CentOS 5.6 64-bit running on Intel Xeon E5-2690v3 (gcc Compiler Version 4.1.2)
|-
|DataGravity Discovery Series OS V2.0 running on Intel Xeon E5-2420 (x86) with AES-NI (gcc Compiler Version 4.7.2)
|-
|DataGravity Discovery Series OS V2.0 running on Intel Xeon E5-2420 (x86) without AES-NI (gcc Compiler Version 4.7.2)
|-
|DSP Media Framework 1.4 running on TI C64x+ (TMS320C6x C/C++ Compiler v6.0.13)
|-
|DSP Media Framework 1.4 (TMS320C6x C/C++ Compiler v6.0.13)
|-
|eCos 3 running on Freescale i.MX27 926ejs (ARMv5TEJ) (gcc Compiler Version 4.3.2)
|-
|Fedora 14 running on Intel Core i5 with AES-NI (gcc Compiler Version 4.5.1)
|-
|FreeBSD 10.0 running on Xeon E5- 2430L (x86) with AES-NI (clang Compiler Version 3.3)
|-
|FreeBSD 10.0 running on Xeon E5-2430L (x86) with AES-NI (clang Compiler Version 3.3)
|-
|FreeBSD 10.0 running on Xeon E5-2430L (x86) without AES-NI (clang Compiler Version 3.3)
|-
|FreeBSD 10.2 running on Intel Xeon E5-2430L (x86) with AES-NI (clang Compiler Version 3.4.1)
|-
|FreeBSD 10.2 running on Intel Xeon E5-2430L (x86) without AES-NI (clang Compiler Version 3.4.1)
|-
|FreeBSD 8.4 running on Intel Xeon E5440 (x86) 32-bit (gcc Compiler Version 4.2.1)
|-
|FreeBSD 8.4 running on Intel Xeon E5440 (x86) without AES-NI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 8.4 running on Intel Xeon E5440 (x86) without AESNI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 9.1 running on Xeon E5-2430L (x86) with AES-NI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 9.1 running on Xeon E5-2430L (x86) without AES-NI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 9.1 running on Xeon E5-2430L (x86) without AESNI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 9.2 running on Xeon E5-2430L (x86) with AES-NI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 9.2 running on Xeon E5-2430L (x86) without AES-NI (gcc Compiler Version 4.2.1)
|-
|HP-UX 11i (32 bit) (HP C/aC++ B3910B)
|-
|HP-UX 11i (32 bit) running on Intel Itanium 2 (HP C/aC++ B3910B)
|-
|HP-UX 11i (64 bit) (HP C/aC++ B3910B)
|-
|HP-UX 11i (64 bit) running on Intel Itanium 2 (HP C/aC++ B3910B)
|-
|iOS 6.0 running on Apple A5 / ARM Cortex-A9 (ARMv7) with NEON (gcc Compiler Version 4.2.1)
|-
|iOS 6.0 running on Apple A5 / ARM Cortex-A9 (ARMv7) without NEON (gcc Compiler Version 4.2.1)
|-
|iOS 8.1 32bit running on Apple A7 (ARMv8) with NEON (clang Compiler Version 600.0.56)
|-
|iOS 8.1 32-bit running on Apple A7 (ARMv8) with NEON (clang Compiler Version 600.0.56)
|-
|iOS 8.1 32bit running on Apple A7 (ARMv8) without NEON (clang Compiler Version 600.0.56)
|-
|iOS 8.1 32-bit running on Apple A7 (ARMv8) without NEON (clang Compiler Version 600.0.56)
|-
|iOS 8.1 64bit running on Apple A7 (ARMv8) with NEON and Crypto Extensions (clang Compiler Version 600.0.56)
|-
|iOS 8.1 64-bit running on Apple A7 (ARMv8) with NEON and Crypto Extensions (clang Compiler Version 600.0.56)
|-
|iOS 8.1 64bit running on Apple A7 (ARMv8) without NEON and Crypto Extensions (clang Compiler Version 600.0.56)
|-
|iOS 8.1 64-bit running on Apple A7 (ARMv8) without NEON and Crypto Extensions (clang Compiler Version 600.0.56)
|-
|iOS 8.1 64-bit running on Apple A7 (ARMv8) without NEON and Crypto Extensions (clang Compilerv Version 600.0.56)
|-
|Linux 2.6.27 (gcc Compiler Version 4.2.4)
|-
|Linux 2.6.27 running on PowerPC e300c3 (gcc Compiler Version 4.2.4)
|-
|Linux 2.6.32 (gcc Compiler Version 4.3.2)
|-
|Linux 2.6.32 running on TI AM3703CBP (ARMv7) (gcc Compiler Version 4.3.2)
|-
|Linux 2.6.33 (gcc Compiler Version 4.1.0)
|-
|Linux 2.6.33 running on PowerPC32 e300 (gcc Compiler Version 4.1.0)
|-
|Linux 2.6 (gcc Compiler Version 4.1.0)
|-
|Linux 2.6 (gcc Compiler Version 4.3.2)
|-
|Linux 2.6 running on a Nimble Storage CS300 with AES-NI
|-
|Linux 2.6 running on a Nimble Storage CS500 with AES-NI
|-
|Linux 2.6 running on a Nimble Storage CS700 with AES-NI
|-
|Linux 2.6 running on Broadcom BCM11107 (ARMv6) (gcc Compiler Version 4.3.2)
|-
|Linux 2.6 running on Freescale e500v2 (PPC) (gcc Compiler Version 4.4.1)
|-
|Linux 2.6 running on Freescale PowerPCe500 (gcc Compiler Version 4.1.0)
|-
|Linux 2.6 running on TI TMS320DM6446 (ARMv4) (gcc Compiler Version 4.3.2)
|-
|Linux 3.10 32-bit running on Intel Atom E3845 (x86) with AES-NI (gcc Compiler Version 4.8.1)
|-
|Linux 3.10 32-bit running on Intel Atom E3845 (x86) without AES-NI (gcc Compiler Version 4.8.1)
|-
|Linux 3.10 on VMware ESXi 6.00 running on Intel Xeon with AES-NI (gcc Compiler Version 4.8.3)
|-
|Linux 3.10 on Vmware ESXi 6.00 running on Intel Xeon without AES-NI (gcc Compiler Version 4.8.3)
|-
|Linux 3.10 running on Intel Xeon with AES-NI (gcc Compiler Version 4.8.3)
|-
|Linux 3.10 running on Intel Xeon without AES-NI (gcc Compiler Version 4.8.3)
|-
|Linux 3.4 64-bit under Citrix XenServer running on Intel Xeon E5-2430L (x86) without AES-NI
|-
|Linux 3.4 under Citrix XenServer 6.2 running on Intel Xeon E5-2430L with AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.4 under Citrix XenServer 6.2 running on Intel Xeon E5-2430L without AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.4 under Microsoft Windows 2012 Hyper-V running on Intel Xeon E5-2430L with AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.4 under Microsoft Windows 2012 Hyper-V running on Intel Xeon E5-2430L with AES-NI (gcc Compiler Version 4.8.0)2
|-
|Linux 3.4 under Microsoft Windows 2012 Hyper-V running on Intel Xeon E5-2430L without AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.4 under Vmware ESXi 5.1 running on Intel Xeon E5-2430L with AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.4 under Vmware ESXi 5.1 running on Intel Xeon E5-2430L without AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.8 running on ARM926 (ARMv5TEJ) (gcc Compiler Version 4.7.3)
|-
|Linux ORACLESP 2.6 running on ASPEED AST-Series (ARMv5) (gcc Compiler Version 4.4.5)
|-
|Linux ORACLESP 2.6 running on Emulex PILOT3 (ARMv5) (gcc Compiler Version 4.4.5)
|-
|Microsoft Windows 7 (32 bit) (Microsoft 32 bit C/C++ Optimizing Compiler Version 16.00)
|-
|Microsoft Windows 7 (32 bit) running on Intel Celeron (Microsoft 32 bit C/C++ Optimizing Compiler Version 16.00)
|-
|Microsoft Windows 7 (64 bit) (Microsoft C/C++ Optimizing Compiler Version 16.00)
|-
|Microsoft Windows 7 (64 bit) running on Intel Pentium 4 (Microsoft C/C++ Optimizing Compiler Version 16.00)
|-
|Microsoft Windows 7 running on Intel Core i5- 2430M (64-bit) with AES-NI (Microsoft ® C/C++ Optimizing Compiler Version 16.00 for x64)
|-
|Microsoft Windows 7 running on Intel Core i5-2430M (64-bit) with AES-NI (Microsoft « C/C++ Optimizing Compiler Version 16.00 for x64)
|-
|Microsoft Windows CE 5.0 (Microsoft C/C++ Optimizing Compiler Version 13.10 for ARM)
|-
|Microsoft Windows CE 5.0 running on ARMv7 (Microsoft C/C++ Optimizing Compiler Version 13.10 for ARM)
|-
|Microsoft Windows CE 6.0 (Microsoft C/C++ Optimizing Compiler Version 15.00 for ARM)
|-
|Microsoft Windows CE 6.0 running on ARMv5TEJ (Microsoft C/C++ Optimizing Compiler Version 15.00 for ARM)
|-
|Microsoft Windows Server 2008 R2 running on an Intel Xeon E5-2420 (x64) (Microsoft 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86)
|-
|NetBSD 5.1 (gcc Compiler Version 4.1.3)
|-
|NetBSD 5.1 running on Intel Xeon 5500 (gcc Compiler Version 4.1.3)
|-
|NetBSD 5.1 running on PowerPCe500 (gcc Compiler Version 4.1.3)
|-
|OpenWRT 2.6 running on MIPS 24Kc (gcc Compiler Version 4.6.3)
|-
|Oracle Linux 5 (64 bit) (gcc Compiler Version 4.1.2)
|-
|Oracle Linux 5 (64 bit) running on Intel Xeon 5675 (gcc Compiler Version 4.1.2)
|-
|Oracle Linux 5 running on Intel Xeon 5675 with AES-NI (gcc Compiler Version 4.1.2)
|-
|Oracle Linux 6 (gcc Compiler Version 4.4.6)
|-
|Oracle Linux 6 running on Intel Xeon 5675 with AES-NI (gcc Compiler Version 4.4.6)
|-
|Oracle Linux 6 running on Intel Xeon 5675 without AES-NI (gcc Compiler Version 4.4.6)
|-
|Oracle Solaris 10 (32 bit) (gcc Compiler Version 3.4.3)
|-
|Oracle Solaris 10 (32 bit) running on SPARC-T3 (SPARCv9) (gcc Compiler Version3.4.3)
|-
|Oracle Solaris 10 (64 bit) (gcc Compiler Version 3.4.3)
|-
|Oracle Solaris 10 (64 bit) running on SPARC-T3 (SPARCv9) (gcc Compiler Version 3.4.3)
|-
|Oracle Solaris 11(32 bit) (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 (32 bit) running on Intel Xeon 5675 (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 (32 bit) running on SPARC-T3 (SPARCv9) (Sun C Version 5.12)
|-
|Oracle Solaris 11 (32 bit) (Sun C Version 5.12)
|-
|Oracle Solaris 11 (64 bit) (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 (64 bit) running on Intel Xeon 5675 (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 (64 bit) running on SPARC-T3 (SPARCv9) (Sun C Version 5.12)
|-
|Oracle Solaris 11 (64 bit) (Sun C Version 5.12)
|-
|Oracle Solaris 11 running on Intel Xeon 5675 with AES-NI (32 bit) (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 running on Intel Xeon 5675 with AESNI (32 bit) (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 running on Intel Xeon 5675 with AES-NI (64 bit) (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 running on Intel Xeon 5675 with AESNI (64 bit) (gcc Compiler Version 4.5.2)
|-
|PexOS 1.0 under vSphere ESXi 5.1 running on Intel Xeon E52430L with AES-NI (gcc Compiler Version 4.6.3)3
|-
|PexOS 1.0 under vSphere ESXi 5.1 running on Intel Xeon E52430L without AES-NI (gcc Compiler Version 4.6.3)
|-
|QNX 6.4 running on Freescale i.MX25 (ARMv4) (gcc Compiler Version 4.3.3)
|-
|QNX 6.5 running on Freescale i.MX25 (ARMv4) (gcc Compiler Version 4.3.3)
|-
|TS-Linux 2.4 running on Arm920Tid (ARMv4) (gcc Compiler Version 4.3.2)
|-
|TS-Linux 2.4 running on Arm920Tid (ARMv4) (gcc Compiler Version 4.3.2)4
|-
|Ubuntu 10.04 (32 bit) (gcc Compiler Version 4.1.3)
|-
|Ubuntu 10.04 (32 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.1.3)
|-
|Ubuntu 10.04 (64 bit) (gcc Compiler Version 4.1.3)
|-
|Ubuntu 10.04 (64 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.1.3)
|-
|Ubuntu 10.04 running on Intel Core i5 with AES-NI (32 bit) (gcc Compiler Version 4.1.3)
|-
|Ubuntu 10.04 running on Intel Pentium T4200 (gcc Compiler Version 4.1.3)
|-
|Ubuntu 12.04 running on Intel Xeon E5-2430L (x86) with AES-NI (gcc Compiler Version 4.6.3)
|-
|Ubuntu 12.04 running on Intel Xeon E5-2430L (x86) without AES-NI (gcc Compiler Version 4.6.3)
|-
|Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) (gcc Compiler Version 4.7.3)
|-
|Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) with NEON (gcc Compiler Version 4.7.3)
|-
|Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) without NEON (gcc Compiler Version 4.7.3)
|-
|uCLinux 0.9.29 (gcc Compiler Version 4.2.1)
|-
|uCLinux 0.9.29 running on ARM 922T (ARMv4) (gcc Compiler Version 4.2.1)
|-
|Vmware Horizon Workspace 1.5 under Vmware ESXi 5.0 running on Intel Xeon E3-1220 (x86) with AES-NI (gcc Compiler Version 4.5.1)1
|-
|Vmware Horizon Workspace 1.5 under Vmware ESXi 5.0 running on Intel Xeon E3-1220 (x86) without AES-NI (gcc Compiler Version 4.5.1)
|-
|Vmware Horizon Workspace 2.1 under vSphere ESXi 5.5 running on Intel Xeon E3-1220 (x86) with AES-NI (gcc Compiler Version 4.5.1)
|-
|Vmware Horizon Workspace 2.1 under vSphere ESXi 5.5 running on Intel Xeon E3-1220 (x86) with AESNI (gcc Compiler Version 4.5.1)
|-
|Vmware Horizon Workspace 2.1 under vSphere ESXi 5.5 running on Intel Xeon E3-1220 (x86) without AES-NI (gcc Compiler Version 4.5.1)
|-
|VxWorks 6.7 running on Intel Core 2 Duo (x86) (gcc Compiler Version 4.1.2)
|-
|VxWorks 6.8 (gcc Compiler Version 4.1.2)
|-
|VxWorks 6.8 running on TI TNETV1050 (MIPS) (gcc Compiler Version 4.1.2)
|-
|VxWorks 6.9 running on Freescale P2020 (PPC) (gcc Compiler Version 4.3.3)
|-
|Windows Embedded Compact 7 running on Freescale i.MX53xA (ARMv7) with NEON (Microsoft C/C++ Optimizing Compiler Version 15.00.20720)
|-
|Windows Embedded Compact 7 running on Freescale i.MX53xD (ARMv7) with NEON (Microsoft C/C++ Optimizing Compiler Version 15.00.20720)
|}

FIPS module 2.0

2016-09-20T14:59:06Z

Stevem: initial draft

The ''OpenSSL FIPS Object Module 2.0'' was first validated with FIPS 140-2 certificate [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 #1747] in mid-2013. This 2.0 FIPS module is compatible with OpenSSL releases 1.0.1 and 1.0.2, and not with any other releases.

Thanks to the [http://openssl.com/fips/hostage.html "hostage issue"] in 2015, two new "clone" validations (known as "Alternative Scenario 1A" validations, also referred to as "re-brand" validations by some test labs) were obtained for the same module. The "RE" validation, [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2473 #2473], was intended to be identical to #1747 while allowing the addition of new platforms. The "SE" validation, [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2398 #2398], was intended for the addition of platforms requiring source code mods and thus new revisions to the module tarball. The #1747 and #2473 validations will forever remain at revision 2.0.10, while new revisions will be added to #2398 (which is at 2.0.13 as of September 2016).

Note that although the paperwork for the two clone validations #2398 and #2473 was submitted at the same time, and the two sets of paperwork were precisely identical other than the respective references to "RE" versus "SE" in the module names, they were approved at different times (July and November) with different editorial modifications required by the CMVP for the Security Policy documents. Such inconsistencies are common with FIPS 140-2 validations; the outcome from one validation effort is not necessarily predictive of what will happen for subsequent similar (or even identical) attempts.

In addition to the three validations of the ''OpenSSL FIPS Object Module 2.0'' obtained directly by OpenSSL, some third party vendors have obtained additional "re-brand" validations:

:: [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2676 #2676], Cohesity OpenSSL FIPS Object Module
:: [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2631 #2631], Intel OpenSSL FIPS Object Module
:: [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2575 #2575], Cellcrypt Secure Core 3 FIPS 140-2 Module
:: [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2454 #2454], LogRhythm FIPS Object Module Version 6.3.4
:: [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2454 #2422], Nimble Storage OpenSSL FIPS Object Module

Noe that while these clone validations have re-branded proprietary module names, they reference the original ''OpenSSL FIPS Object Module 2.0'' tarballs which are available under the open source OpenSSL license, and hence these valdidations can be used and cited by anyone.

A list of formally tested platforms ("Operational Environments") is associated with each validation. Collectively there are over two hundred unique platforms listed across all the ''OpenSSL FIPS Object Module 2.0'' validations:

{| class="wikitable"
|+Unique platforms across all ''OpenSSL FIPS Object Module 2.0'' validations as of 2016-09
|-
|AcanOS 1.0 running on Feroceon 88FR131 (ARMv5) (gcc Compiler Version 4.5.3)
|-
|AcanOS 1.0 running on Intel Core i7-3612QE (x86) with AES-NI (gcc Compiler Version 4.6.2)
|-
|AcanOS 1.0 running on Intel Core i7-3612QE (x86) without AES-NI (gcc Compiler Version 4.6.2)
|-
|AIX 6.1 32-bit running on IBM POWER 7 (PPC) (IBM XL C/C++ for AIX Compiler Version V13.1)
|-
|AIX 6.1 32-bit running on IBM POWER 7 (PPC) with optimizations (IBM XL C/C++ for AIX Compiler Version V10.1)
|-
|AIX 6.1 64-bit running on IBM POWER 7 (PPC) (IBM XL C/C++ for AIX Compiler Version V13.1)
|-
|AIX 6.1 64-bit running on IBM POWER 7 (PPC) with optimizations (IBM XL C/C++ for AIX Compiler Version V10.1)
|-
|AIX 7.1 32-bit running on IBM POWER 7 (PPC) (IBM XL C/C++ for AIX Compiler Version V13.1)
|-
|AIX 7.1 64-bit running on IBM POWER 7 (PPC) (IBM XL C/C++ for AIX Compiler Version V13.1)
|-
|Android 2.2 (gcc Compiler Version 4.4.0)
|-
|Android 2.2 running on OMAP 3530 (ARMv7) with NEON (gcc Compiler Version 4.1.0)
|-
|Android 2.2 running on Qualcomm QSD8250 (ARMv7) with NEON (gcc Compiler Version 4.4.0)
|-
|Android 2.2 running on Qualcomm QSD8250 (ARMv7) without NEON (gcc Compiler Version 4.4.0)
|-
|Android 3.0 (gcc Compiler Version 4.4.0)
|-
|Android 3.0 running on NVIDIA Tegra 250 T20 (ARMv7) (gcc Compiler Version 4.4.0)
|-
|Android 4.0 (gcc Compiler Version 4.4.3)
|-
|Android 4.0 running on NVIDIA Tegra 250 T20 (ARMv7) (gcc Compiler Version 4.4.3)
|-
|Android 4.0 running on Qualcomm Snapdragon APQ8060 (ARMv7) with NEON (gcc compiler Version 4.4.3)
|-
|Android 4.0 running on TI OMAP 3 (ARMv7) with NEON (gcc Compiler Version 4.4.3)
|-
|Android 4.1 running on TI DM3730 (ARMv7) (gcc Compiler Version 4.6)
|-
|Android 4.1 running on TI DM3730 (ARMv7) with NEON (gcc Complier Version 4.6)
|-
|Android 4.1 running on TI DM3730 (ARMv7) without NEON (gcc Compiler Version 4.6)
|-
|Android 4.2 running on Nvidia Tegra 3 (ARMv7) (gcc Compiler Version 4.6)
|-
|Android 4.2 running on Nvidia Tegra 3 (ARMv7) with Neon (gcc Compiler Version 4.6)
|-
|Android 4.2 running on Nvidia Tegra 3 (ARMv7) with NEON (gcc Compiler Version 4.6)
|-
|Android 4.2 running on Nvidia Tegra 3 (ARMv7) without NEON (gcc Compiler Version 4.6)
|-
|Android 5.0 32-bit running on Qualcomm APQ8084 (ARMv7) with NEON (gcc Compiler Version 4.9)
|-
|Android 5.0 32-bit running on Qualcomm APQ8084 (ARMv7) without NEON (gcc Compiler Version 4.9)
|-
|Android 5.0 64-bit running on SAMSUNG Exynos7420 (ARMv8) with NEON and Crypto Extensions (gcc Compiler Version 4.9)
|-
|Android 5.0 64-bit running on SAMSUNG Exynos7420 (ARMv8) without NEON and Crypto Extensions (gcc Compiler Version 4.9)
|-
|Apple iOS 5.0 running on ARM Cortex A8 (ARMv7) with NEON (gcc Compiler Version 4.2.1)
|-
|Apple iOS 5.1 (gcc Compiler Version 4.2.1)
|-
|Apple iOS 5.1 running on ARMv7 (gcc Compiler Version 4.2.1)
|-
|Apple iOS 6.1 running on Apple A6X SoC (ARMv7s) (gcc Compiler Version 4.2.1)
|-
|Apple iOS 7.1 64-bit running on Apple A7 (ARMv8) with NEON (clang Compiler Version 5.1)
|-
|Apple iOS 7.1 64- bit running on Apple A7 (ARMv8) without NEON (clang Compiler Version 5.1)
|-
|Apple OS X 10.7 running on Intel Core i7-3615QM (Apple LLVM version 4.2)
|-
|ArbOS 5.3 running on Xeon E5645 (x86) with AES-NI (gcc Compiler Version 4.1.2)
|-
|ArbOS 5.3 running on Xeon E5645 (x86) without AES-NI (gcc Compiler Version 4.1.2)
|-
|CascadeOS 6.1 (32 bit) (gcc Compiler Version 4.4.5)
|-
|CascadeOS 6.1 (32 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.4.5)
|-
|CascadeOS 6.1 (64 bit) (gcc Compiler Version 4.4.5)
|-
|CascadeOS 6.1 (64 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.4.5)
|-
|CentOS 5.6 64-bit running on Intel Xeon E5-2620v3 (gcc Compiler Version 4.1.2)
|-
|CentOS 5.6 64-bit running on Intel Xeon E5-2690v3 (gcc Compiler Version 4.1.2)
|-
|DataGravity Discovery Series OS V2.0 running on Intel Xeon E5-2420 (x86) with AES-NI (gcc Compiler Version 4.7.2)
|-
|DataGravity Discovery Series OS V2.0 running on Intel Xeon E5-2420 (x86) without AES-NI (gcc Compiler Version 4.7.2)
|-
|DSP Media Framework 1.4 running on TI C64x+ (TMS320C6x C/C++ Compiler v6.0.13)
|-
|DSP Media Framework 1.4 (TMS320C6x C/C++ Compiler v6.0.13)
|-
|eCos 3 running on Freescale i.MX27 926ejs (ARMv5TEJ) (gcc Compiler Version 4.3.2)
|-
|Fedora 14 running on Intel Core i5 with AES-NI (gcc Compiler Version 4.5.1)
|-
|FreeBSD 10.0 running on Xeon E5- 2430L (x86) with AES-NI (clang Compiler Version 3.3)
|-
|FreeBSD 10.0 running on Xeon E5-2430L (x86) with AES-NI (clang Compiler Version 3.3)
|-
|FreeBSD 10.0 running on Xeon E5-2430L (x86) without AES-NI (clang Compiler Version 3.3)
|-
|FreeBSD 10.2 running on Intel Xeon E5-2430L (x86) with AES-NI (clang Compiler Version 3.4.1)
|-
|FreeBSD 10.2 running on Intel Xeon E5-2430L (x86) without AES-NI (clang Compiler Version 3.4.1)
|-
|FreeBSD 8.4 running on Intel Xeon E5440 (x86) 32-bit (gcc Compiler Version 4.2.1)
|-
|FreeBSD 8.4 running on Intel Xeon E5440 (x86) without AES-NI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 8.4 running on Intel Xeon E5440 (x86) without AESNI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 9.1 running on Xeon E5-2430L (x86) with AES-NI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 9.1 running on Xeon E5-2430L (x86) without AES-NI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 9.1 running on Xeon E5-2430L (x86) without AESNI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 9.2 running on Xeon E5-2430L (x86) with AES-NI (gcc Compiler Version 4.2.1)
|-
|FreeBSD 9.2 running on Xeon E5-2430L (x86) without AES-NI (gcc Compiler Version 4.2.1)
|-
|HP-UX 11i (32 bit) (HP C/aC++ B3910B)
|-
|HP-UX 11i (32 bit) running on Intel Itanium 2 (HP C/aC++ B3910B)
|-
|HP-UX 11i (64 bit) (HP C/aC++ B3910B)
|-
|HP-UX 11i (64 bit) running on Intel Itanium 2 (HP C/aC++ B3910B)
|-
|iOS 6.0 running on Apple A5 / ARM Cortex-A9 (ARMv7) with NEON (gcc Compiler Version 4.2.1)
|-
|iOS 6.0 running on Apple A5 / ARM Cortex-A9 (ARMv7) without NEON (gcc Compiler Version 4.2.1)
|-
|iOS 8.1 32bit running on Apple A7 (ARMv8) with NEON (clang Compiler Version 600.0.56)
|-
|iOS 8.1 32-bit running on Apple A7 (ARMv8) with NEON (clang Compiler Version 600.0.56)
|-
|iOS 8.1 32bit running on Apple A7 (ARMv8) without NEON (clang Compiler Version 600.0.56)
|-
|iOS 8.1 32-bit running on Apple A7 (ARMv8) without NEON (clang Compiler Version 600.0.56)
|-
|iOS 8.1 64bit running on Apple A7 (ARMv8) with NEON and Crypto Extensions (clang Compiler Version 600.0.56)
|-
|iOS 8.1 64-bit running on Apple A7 (ARMv8) with NEON and Crypto Extensions (clang Compiler Version 600.0.56)
|-
|iOS 8.1 64bit running on Apple A7 (ARMv8) without NEON and Crypto Extensions (clang Compiler Version 600.0.56)
|-
|iOS 8.1 64-bit running on Apple A7 (ARMv8) without NEON and Crypto Extensions (clang Compiler Version 600.0.56)
|-
|iOS 8.1 64-bit running on Apple A7 (ARMv8) without NEON and Crypto Extensions (clang Compilerv Version 600.0.56)
|-
|Linux 2.6.27 (gcc Compiler Version 4.2.4)
|-
|Linux 2.6.27 running on PowerPC e300c3 (gcc Compiler Version 4.2.4)
|-
|Linux 2.6.32 (gcc Compiler Version 4.3.2)
|-
|Linux 2.6.32 running on TI AM3703CBP (ARMv7) (gcc Compiler Version 4.3.2)
|-
|Linux 2.6.33 (gcc Compiler Version 4.1.0)
|-
|Linux 2.6.33 running on PowerPC32 e300 (gcc Compiler Version 4.1.0)
|-
|Linux 2.6 (gcc Compiler Version 4.1.0)
|-
|Linux 2.6 (gcc Compiler Version 4.3.2)
|-
|Linux 2.6 running on a Nimble Storage CS300 with AES-NI
|-
|Linux 2.6 running on a Nimble Storage CS500 with AES-NI
|-
|Linux 2.6 running on a Nimble Storage CS700 with AES-NI
|-
|Linux 2.6 running on Broadcom BCM11107 (ARMv6) (gcc Compiler Version 4.3.2)
|-
|Linux 2.6 running on Freescale e500v2 (PPC) (gcc Compiler Version 4.4.1)
|-
|Linux 2.6 running on Freescale PowerPCe500 (gcc Compiler Version 4.1.0)
|-
|Linux 2.6 running on TI TMS320DM6446 (ARMv4) (gcc Compiler Version 4.3.2)
|-
|Linux 3.10 32-bit running on Intel Atom E3845 (x86) with AES-NI (gcc Compiler Version 4.8.1)
|-
|Linux 3.10 32-bit running on Intel Atom E3845 (x86) without AES-NI (gcc Compiler Version 4.8.1)
|-
|Linux 3.10 on VMware ESXi 6.00 running on Intel Xeon with AES-NI (gcc Compiler Version 4.8.3)
|-
|Linux 3.10 on Vmware ESXi 6.00 running on Intel Xeon without AES-NI (gcc Compiler Version 4.8.3)
|-
|Linux 3.10 running on Intel Xeon with AES-NI (gcc Compiler Version 4.8.3)
|-
|Linux 3.10 running on Intel Xeon without AES-NI (gcc Compiler Version 4.8.3)
|-
|Linux 3.4 64-bit under Citrix XenServer running on Intel Xeon E5-2430L (x86) without AES-NI
|-
|Linux 3.4 under Citrix XenServer 6.2 running on Intel Xeon E5-2430L with AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.4 under Citrix XenServer 6.2 running on Intel Xeon E5-2430L without AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.4 under Microsoft Windows 2012 Hyper-V running on Intel Xeon E5-2430L with AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.4 under Microsoft Windows 2012 Hyper-V running on Intel Xeon E5-2430L with AES-NI (gcc Compiler Version 4.8.0)2
|-
|Linux 3.4 under Microsoft Windows 2012 Hyper-V running on Intel Xeon E5-2430L without AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.4 under Vmware ESXi 5.1 running on Intel Xeon E5-2430L with AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.4 under Vmware ESXi 5.1 running on Intel Xeon E5-2430L without AES-NI (gcc Compiler Version 4.8.0)
|-
|Linux 3.8 running on ARM926 (ARMv5TEJ) (gcc Compiler Version 4.7.3)
|-
|Linux ORACLESP 2.6 running on ASPEED AST-Series (ARMv5) (gcc Compiler Version 4.4.5)
|-
|Linux ORACLESP 2.6 running on Emulex PILOT3 (ARMv5) (gcc Compiler Version 4.4.5)
|-
|Microsoft Windows 7 (32 bit) (Microsoft 32 bit C/C++ Optimizing Compiler Version 16.00)
|-
|Microsoft Windows 7 (32 bit) running on Intel Celeron (Microsoft 32 bit C/C++ Optimizing Compiler Version 16.00)
|-
|Microsoft Windows 7 (64 bit) (Microsoft C/C++ Optimizing Compiler Version 16.00)
|-
|Microsoft Windows 7 (64 bit) running on Intel Pentium 4 (Microsoft C/C++ Optimizing Compiler Version 16.00)
|-
|Microsoft Windows 7 running on Intel Core i5- 2430M (64-bit) with AES-NI (Microsoft ® C/C++ Optimizing Compiler Version 16.00 for x64)
|-
|Microsoft Windows 7 running on Intel Core i5-2430M (64-bit) with AES-NI (Microsoft « C/C++ Optimizing Compiler Version 16.00 for x64)
|-
|Microsoft Windows CE 5.0 (Microsoft C/C++ Optimizing Compiler Version 13.10 for ARM)
|-
|Microsoft Windows CE 5.0 running on ARMv7 (Microsoft C/C++ Optimizing Compiler Version 13.10 for ARM)
|-
|Microsoft Windows CE 6.0 (Microsoft C/C++ Optimizing Compiler Version 15.00 for ARM)
|-
|Microsoft Windows CE 6.0 running on ARMv5TEJ (Microsoft C/C++ Optimizing Compiler Version 15.00 for ARM)
|-
|Microsoft Windows Server 2008 R2 running on an Intel Xeon E5-2420 (x64) (Microsoft 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86)
|-
|NetBSD 5.1 (gcc Compiler Version 4.1.3)
|-
|NetBSD 5.1 running on Intel Xeon 5500 (gcc Compiler Version 4.1.3)
|-
|NetBSD 5.1 running on PowerPCe500 (gcc Compiler Version 4.1.3)
|-
|OpenWRT 2.6 running on MIPS 24Kc (gcc Compiler Version 4.6.3)
|-
|Oracle Linux 5 (64 bit) (gcc Compiler Version 4.1.2)
|-
|Oracle Linux 5 (64 bit) running on Intel Xeon 5675 (gcc Compiler Version 4.1.2)
|-
|Oracle Linux 5 running on Intel Xeon 5675 with AES-NI (gcc Compiler Version 4.1.2)
|-
|Oracle Linux 6 (gcc Compiler Version 4.4.6)
|-
|Oracle Linux 6 running on Intel Xeon 5675 with AES-NI (gcc Compiler Version 4.4.6)
|-
|Oracle Linux 6 running on Intel Xeon 5675 without AES-NI (gcc Compiler Version 4.4.6)
|-
|Oracle Solaris 10 (32 bit) (gcc Compiler Version 3.4.3)
|-
|Oracle Solaris 10 (32 bit) running on SPARC-T3 (SPARCv9) (gcc Compiler Version3.4.3)
|-
|Oracle Solaris 10 (64 bit) (gcc Compiler Version 3.4.3)
|-
|Oracle Solaris 10 (64 bit) running on SPARC-T3 (SPARCv9) (gcc Compiler Version 3.4.3)
|-
|Oracle Solaris 11(32 bit) (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 (32 bit) running on Intel Xeon 5675 (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 (32 bit) running on SPARC-T3 (SPARCv9) (Sun C Version 5.12)
|-
|Oracle Solaris 11 (32 bit) (Sun C Version 5.12)
|-
|Oracle Solaris 11 (64 bit) (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 (64 bit) running on Intel Xeon 5675 (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 (64 bit) running on SPARC-T3 (SPARCv9) (Sun C Version 5.12)
|-
|Oracle Solaris 11 (64 bit) (Sun C Version 5.12)
|-
|Oracle Solaris 11 running on Intel Xeon 5675 with AES-NI (32 bit) (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 running on Intel Xeon 5675 with AESNI (32 bit) (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 running on Intel Xeon 5675 with AES-NI (64 bit) (gcc Compiler Version 4.5.2)
|-
|Oracle Solaris 11 running on Intel Xeon 5675 with AESNI (64 bit) (gcc Compiler Version 4.5.2)
|-
|PexOS 1.0 under vSphere ESXi 5.1 running on Intel Xeon E52430L with AES-NI (gcc Compiler Version 4.6.3)3
|-
|PexOS 1.0 under vSphere ESXi 5.1 running on Intel Xeon E52430L without AES-NI (gcc Compiler Version 4.6.3)
|-
|QNX 6.4 running on Freescale i.MX25 (ARMv4) (gcc Compiler Version 4.3.3)
|-
|QNX 6.5 running on Freescale i.MX25 (ARMv4) (gcc Compiler Version 4.3.3)
|-
|TS-Linux 2.4 running on Arm920Tid (ARMv4) (gcc Compiler Version 4.3.2)
|-
|TS-Linux 2.4 running on Arm920Tid (ARMv4) (gcc Compiler Version 4.3.2)4
|-
|Ubuntu 10.04 (32 bit) (gcc Compiler Version 4.1.3)
|-
|Ubuntu 10.04 (32 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.1.3)
|-
|Ubuntu 10.04 (64 bit) (gcc Compiler Version 4.1.3)
|-
|Ubuntu 10.04 (64 bit) running on Intel Pentium T4200 (gcc Compiler Version 4.1.3)
|-
|Ubuntu 10.04 running on Intel Core i5 with AES-NI (32 bit) (gcc Compiler Version 4.1.3)
|-
|Ubuntu 10.04 running on Intel Pentium T4200 (gcc Compiler Version 4.1.3)
|-
|Ubuntu 12.04 running on Intel Xeon E5-2430L (x86) with AES-NI (gcc Compiler Version 4.6.3)
|-
|Ubuntu 12.04 running on Intel Xeon E5-2430L (x86) without AES-NI (gcc Compiler Version 4.6.3)
|-
|Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) (gcc Compiler Version 4.7.3)
|-
|Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) with NEON (gcc Compiler Version 4.7.3)
|-
|Ubuntu 13.04 running on AM335x Cortex-A8 (ARMv7) without NEON (gcc Compiler Version 4.7.3)
|-
|uCLinux 0.9.29 (gcc Compiler Version 4.2.1)
|-
|uCLinux 0.9.29 running on ARM 922T (ARMv4) (gcc Compiler Version 4.2.1)
|-
|Vmware Horizon Workspace 1.5 under Vmware ESXi 5.0 running on Intel Xeon E3-1220 (x86) with AES-NI (gcc Compiler Version 4.5.1)1
|-
|Vmware Horizon Workspace 1.5 under Vmware ESXi 5.0 running on Intel Xeon E3-1220 (x86) without AES-NI (gcc Compiler Version 4.5.1)
|-
|Vmware Horizon Workspace 2.1 under vSphere ESXi 5.5 running on Intel Xeon E3-1220 (x86) with AES-NI (gcc Compiler Version 4.5.1)
|-
|Vmware Horizon Workspace 2.1 under vSphere ESXi 5.5 running on Intel Xeon E3-1220 (x86) with AESNI (gcc Compiler Version 4.5.1)
|-
|Vmware Horizon Workspace 2.1 under vSphere ESXi 5.5 running on Intel Xeon E3-1220 (x86) without AES-NI (gcc Compiler Version 4.5.1)
|-
|VxWorks 6.7 running on Intel Core 2 Duo (x86) (gcc Compiler Version 4.1.2)
|-
|VxWorks 6.8 (gcc Compiler Version 4.1.2)
|-
|VxWorks 6.8 running on TI TNETV1050 (MIPS) (gcc Compiler Version 4.1.2)
|-
|VxWorks 6.9 running on Freescale P2020 (PPC) (gcc Compiler Version 4.3.3)
|-
|Windows Embedded Compact 7 running on Freescale i.MX53xA (ARMv7) with NEON (Microsoft C/C++ Optimizing Compiler Version 15.00.20720)
|-
|Windows Embedded Compact 7 running on Freescale i.MX53xD (ARMv7) with NEON (Microsoft C/C++ Optimizing Compiler Version 15.00.20720)
|}

FIPS modules

2016-09-20T14:22:52Z

Stevem: link to 2.0 module page

There is currently only one extant FIPS 140-2 validated cryptographic module, the ''OpenSSL FIPS Object Module 2.0''. This module is revised periodically with platform portability modifications to support additional platforms (general improvements and bugfixes, even security vulnerability mitigations, are not permitted[http://veridicalsystems.com/blog/immutability-of-fips/]). As of September 2016 the latest module revision is 2.0.13.

The 2.0 module is rather confusingly covered by three very similar validations, the original #1747[http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747] and the "Alternative Scenario 1A" clone validations #2398 [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2398] and #2473 [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2473]. For perverse and inscrutable bureaucratic reasons the #1747 validation cannot be updated and it and #2473 will forever remain at revision 2.0.10. New platforms can be added to #2398 for revision 2.0.10, and new platforms and new revisions can currently be added to the #2398 validation. The choice of validation is a paperwork consideration as all three validations reference the same cryptographic module. Note there are also a number of third party clone validations that also reference exactly the same cryptographic module. Since that module is available under the OpenSSL open source license, any such validation can be cited for satisfying FIPS 140-2 validation requirements. Collectively across all such validations the 2.0 FIPS module has more than two hundred formally tested platforms (known as "Operational Environments" in FIPS-speak). More information about the 2.0 FIPS module can be founf starting at [[FIPS_module_2.0]].

The 2.0 FIPS module is compatible with OpenSSL releases 1.0.1 and 1.0.2, and no others. The extensive internal structural changes for OpenSSL 1.1 preclude the use of the 2.0 FIPS module with that release.

A new validation effort is to develop and validate a new open source based cryptographic module was announced in July 2016[https://www.openssl.org/blog/blog/2016/07/20/fips/]. This new module will be usable with OpenSSL release 1.1. It will provisionally be called ''OpenSSL FIPS Object Module 3.0''. Notes and commentary can be found starting at [[FIPS_module_3.0]].

FIPS module 3.0

2016-09-19T13:39:22Z

Stevem: Caveat entropy goal

FIPS module 3.0

2016-09-19T13:17:10Z

Stevem: Initial draft

FIPS modules

2016-09-19T13:00:10Z

Stevem: Initial draft

There is currently only one extant FIPS 140-2 validated cryptographic module, the ''OpenSSL FIPS Object Module 2.0''. This module is revised periodically with platform portability modifications to support additional platforms (general improvements and bugfixes, even security vulnerability mitigations, are not permitted[http://veridicalsystems.com/blog/immutability-of-fips/]). As of September 2016 the latest module revision is 2.0.13.

The 2.0 module is rather confusingly covered by three very similar validations, the original #1747[http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747] and the "Alternative Scenario 1A" clone validations #2398 [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2398] and #2473 [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2473]. For perverse and inscrutable bureaucratic reasons the #1747 validation cannot be updated and it and #2473 will forever remain at revision 2.0.10. New platforms can be added to #2398 for revision 2.0.10, and new platforms and new revisions can currently be added to the #2398 validation. The choice of validation is a paperwork consideration as all three validations reference the same cryptographic module. Note there are also a number of third party clone validations that also reference exactly the same cryptographic module. Since that module is available under the OpenSSL open source license, any such validation can be cited for satisfying FIPS 140-2 validation requirements. Collectively across all such validations the 2.0 FIPS module has more than two hundred formally tested platforms (known as "Operational Environments" in FIPS-speak).

The 2.0 FIPS module is compatible with OpenSSL releases 1.0.1 and 1.0.2, and no others. The extensive internal structural changes for OpenSSL 1.1 preclude the use of the 2.0 FIPS module with that release.

A new validation effort is to develop and validate a new open source based cryptographic module was announced in July 2016[https://www.openssl.org/blog/blog/2016/07/20/fips/]. This new module will be usable with OpenSSL release 1.1. It will provisionally be called ''OpenSSL FIPS Object Module 3.0''. Notes and commentary can be found starting at [[FIPS_module_3.0]].

Main Page

2016-09-19T12:26:20Z

Stevem: /* OpenSSL Quick Links */

This is the OpenSSL wiki. The main site is https://www.openssl.org . If this is your first visit or to get an account please see the [[Welcome]] page. Your participation and [[Contributions]] are valued.

This wiki is intended as a place for collecting, organizing, and refining useful information about OpenSSL that is currently strewn among multiple locations and formats.

== OpenSSL Quick Links ==

<TABLE border=0>
<TR>
<TD>[[OpenSSL Overview]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Compilation and Installation]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Internals]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Mailing Lists]] </TD>
</TR>
<TR>
<TD>[[libcrypto API]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[libssl API]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Examples]] </TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Documentation Index|Index of all API functions]]</TD>
</TR>
<TR>
<TD>[[License]] </TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Command Line Utilities]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Related Links]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Binaries]]</TD>
</TR>
<TR>
<TD>[[SSL and TLS Protocols]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[1.1 API Changes]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[FIPS modules]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
</TR>
</TABLE>

== Administrivia ==
Site guidelines, legal and admininstrative issues.
:* [[Basic rules]], [[Commercial Product Disclaimer]], [[Contributions]], [[Copyright]], [[License]]
:* Using This Wiki
:: [http://meta.wikimedia.org/wiki/Help:Contents Wiki User's Guide], [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list], [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ], [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki Mailing List]

== Reference ==
This section contains the automagically generated man pages from the OpenSSL git repository, and similar "man" style reference documentation. The man pages are automatically imported from the OpenSSL git repository and local wiki modifications are submitted as patches.
:* OpenSSL Manual Pages
::* [[Manual:Openssl(1)]], [[Manual:Ssl(3)]], [[Manual:Crypto(3)]], [[Documentation Index]]
:: If you wish to edit any of the Manual page content please refer to the [[Guidelines for Manual Page Authors]] page.
:* [[API]], [[Libcrypto API]], [[Libssl API]]
:* [[FIPS mode()]], [[FIPS_mode_set()]]

== Usage and Programming ==
This section has discussions of practical issues in using OpenSSL
:* Building from Source
:: Where to find it, the different versions, how to build and install it.
:* [[OpenSSL Overview]]
:* [[Versioning]]
:* [[Compilation and Installation]]
:* [[EVP]]
:: Programming techniques and example code
:: Use of EVP is preferred for most applications and circumstances
::* [[EVP Asymmetric Encryption and Decryption of an Envelope]]
::* [[EVP Authenticated Encryption and Decryption]]
::* [[EVP Symmetric Encryption and Decryption]]
::* [[EVP Key and Parameter Generation]]
::* [[EVP Key Agreement]]
::* [[EVP Message Digests]]
::* [[EVP Key Derivation]]
::* [[EVP Signing and Verifying|EVP Signing and Verifying (including MAC codes)]]
:* [[STACK API]]
:* Low Level APIs
::[[Creating an OpenSSL Engine to use indigenous ECDH ECDSA and HASH Algorithms]]
:: More specialized non-EVP usage
::* [[Diffie-Hellman parameters]]
:* [[FIPS Mode]]
:* [[Simple TLS Server]]

== Concepts and Theory ==
Discussions of basic cryptographic theory and concepts
Discussions of common operational issues
:* [[Base64]]
:* [http://wiki.openssl.org/index.php/Category:FIPS_140 FIPS 140-2]
:* [[Random Numbers]]
:* [[Diffie Hellman]]
:* [[Elliptic Curve Diffie Hellman]]
:* [[Elliptic Curve Cryptography]]

== Security Advisories ==
:* [https://www.openssl.org/about/secpolicy.html OpenSSL Security Policy]
:* [https://www.openssl.org/news/vulnerabilities.html OpenSSL Vulnerabilities List]
:* [[Security_Advisories|Security Advisories Additional Information]]

== Feedback and Contributions ==
:* [https://www.openssl.org/support/faq.html#BUILD18 How to notify us of suspected security vulnerabilities]
:* [https://www.openssl.org/community/#bugs How to report bugs, other than for suspected vulnerabilities]
:* [[Contributions|General background on source and documentation contributions - '''must read''']]
:* Contributing code fixes, other than for suspected vulnerabilities, as well as fixes and other improvements to manual pages:
::* If you are unsure as to whether a feature will be useful for the general OpenSSL community please discuss it on the [https://www.openssl.org/support/community.html openssl-dev mailing list] first. Someone may be already working on the same thing or there may be a good reason as to why that feature isn't implemented.
::* Follow the [[Use of Git#Use_of_Git_with_OpenSSL_source_tree|instructions for accessing source code]] in the appropriate branches. Note that manual pages and the FAQ are maintained with the source code.
::* Submit a pull request for each separate fix (also documented [[Use of Git#Use_of_Git_with_OpenSSL_source_tree|there]])
::* Submit a bug report (see second bullet, above) and reference the pull request. Or you can attach the patch to the ticket.
:* Contributing fixes and other improvements to the web site
::* Follow the [[Use_of_Git#Use_of_Git_with_the_OpenSSL_web_site|instructions for accessing web site sources]]
::* Create a patch (also documented [[Use_of_Git#Use_of_Git_with_the_OpenSSL_web_site|there]])
::* Submit a bug report and add the patch as an attachment
:* [[Developing For OpenSSL]]
:* [[KnownPatches|Known patches not part of OpenSSL]]
:* [[Welcome|Contributing to this wiki]]

== Internals and Development ==
This section is for internal details of primary interest to OpenSSL maintainers and power users
:* [[Code reformatting]]

:* [[Internals]]
:* [[Code Quality]]
:* [[Static and Dynamic Analysis]]
:* [[OCB|OCB Licence details]]
:* [[Defect and Feature Review Process]]
:* [[Unit Testing]] (includes other automated testing information)

Binaries

2015-11-05T15:45:38Z

Stevem: New page

Some people have offered to provide OpenSSL binary distributions for selected operating systems. The condition to get a link here is that the link is stable and can provide continued support for OpenSSL for a while.

Note: many Linux distributions come with pre-compiled OpenSSL packages. Those are already well-known among the users of said distributions, and will therefore not be mentioned here. If you are such a user, we ask you to get in touch with your distributor first. This service is primarily for operating systems where there are no pre-compiled OpenSSL packages.

'''Important Disclaimer''':
''The listing of these third party products does not imply any endorsement by the OpenSSL project, and these organizations are not affiliated in any way with OpenSSL other than by the reference to their ndependent web sites here. In particular any donations or payments to any of these organizations will not be known to, seen by, or in any way benefit the OpenSSL project.''

Use these OpenSSL derived products at your own risk; these products have not been evaluated or tested by the OpenSSL project.

{| class="wikitable sortable" border="1"
|+ Third Party OpenSSL Related Binary Distributions
|-
! scope="col" | Product
! scope="col" | Description
! scope="col" | URL
|-
| OpenSSL for Windows
| Works with MSVC++, Builder 3/4/5, and MinGW. Comes in form of self-install executables.
| https://slproweb.com/products/Win32OpenSSL.html
|-
|-
| OpenSSL for Windows
| Pre-compiled Win32/64 libraries without external dependencies to the Microsoft Visual Studio Runtime DLLs, except for the system provided msvcrt.dll.
| https://indy.fulgan.com/SSL/
|-
|-
| OpenSSL for Solaris
| Versions for Solaris 2.5 - 11 SPARC and X86
| http://www.unixpackages.com/
|-
|-
|}

FIPS mode and TLS

2014-02-10T13:53:14Z

Stevem: First draft of large new page

The new SP800-131A and FIPS 186-4 restrictions on algorithms and key sizes complicate
the use of ciphersuites for TLS considerably. This page is intended to answer the
question "can I configure an OpenSSL cipherstring for TLS to comply with the new FIPS restrictions?".

This discussion assumes use of a "FIPS capable" OpenSSL 1.0.1f or later.

A new security framework in development for future versions will make enforcing these types
of restrictions easier and the algorithm restrictions are performed all in one place.

== Quick Summary ==

The preferred cipherstring for OpenSSL 1.0.1f+ for all versions of TLS subject to the new FIPS
restrictions is:
<pre>
'TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL'
</pre>
However, multiple caveats apply as discussed below.

Workarounds for OpenSSL releases prior to 1.0.1f are discussed below.

== Detailed discussion ==

The general rule is you can't use SHA1 for digital signatures any more nor
a combination like MD5+SHA1. You *can* use SHA1 for HMAC so there's no need to
force the use of SHA256 HMAC ciphersuites.

A cipherstring in OpenSSL also known as a "cipher list"
https://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS
A cipherstring in OpenSSL is a compact notation for a set of cryptographic algorithms
(public key, symmetric key, and digest algorithms) in order of preference.

The cipherstring notation is discussed at https://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT
Briefly, a cipherstring is a series of elements each designating either a specific ciphersuite or a set of
ciphersuites. The "+" operator designates a logical and operation, so "element1+element1" represents that
set of ciphersuites containing the algorithms in both element1 and element2. The "!" operator permanently
all the algorithms in the following element.

=== TLS 1.0 and 1.1 ===

All TLS 1.0/1.1 authenticated PFS (Perfect Forward Secrecy) ciphersuites use SHA1 alone or MD5+SHA1. That
leaves only unauthenticated ones (which are vulnerable to MiTM so we discount
them) or those using static keys. Theoretically that would permit RSA, DH or
ECDH keys in certificates but in practice everyone uses RSA.

The corresponding cipherstring is:
<pre>
openssl ciphers -v 'kRSA+FIPS:!TLSv1.2'
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
</pre>
That cipherstring specifies three possible ciphersuites allowable in FIPS mode for TLS 1.0 and 1.1.
The RSA key in the certificate has to be of suitable size
(2048 bits minimum) as do all other keys in the chain and none of the CAs can
sign using SHA1. Also those kRSA ciphersuites are allowed for
server certificates only; client authentication is never allowed
with the new rules for TLS 1.0 and 1.1.

In a real application when FIPS mode is enabled then only
FIPS ciphersuites are allowed no matter what you use in the string. So in FIPS mode
"kRSA:!TLSv1.2" will be functionally equivalent to "kRSA+FIPS!TLSv1.2".

Note the "TLSv1.2" string was only added to OpenSSL recently, as of OpenSSL 1.0.1f.
It designates the ciphers for TLSv1.2 subject to the FIPS 140-2 and FIPS 186-4
restrictions.

Note the cipherstring 'FIPS:!TLSv1.2' would also allow fixed DH and fixed ECDH
certificates but those are not encountered in the wild.
The key exchange component "kRSA" specifies just those algorithms that support RSA key exchange.

=== TLS 1.2 ===

TLS 1.2 provides more options as the signature can use an algorithm other
than SHA1.
"kRSA+FIPS" specifies those ciphersuites that use RSA key exchange, including TLS v1.2, *and*
are allowed in FIPS mode, and including anonymous ones which may be undesirable:
<pre>
openssl ciphers -v 'kRSA+FIPS'
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
</pre>
The ephemeral key for the now permitted PFS keys must be at least 2048 bits (DH)
or 256 bits (ECDH) in size. Anything supporting ECDH will probably set P-256 as
a default so that should be OK (Apache does).

There's a snag though. The ciphersuite ECDH-RSA-AES128-SHA can (outside FIPS) be
used for TLS 1.0 and later whereas in FIPS mode it can only be used for TLS v1.2. A
TLS client can't advertise ciphersuites in that way (i.e. you can use this for
TLS1.2 only and nothing earlier) so you're left with the situation where a FIPS
compliant client might say it wants ECDH-RSA-AES128-SHA
and TLS 1.2 and the server only supports TLS 1.0 so it will choke when it tries to
use the prohibited ciphersuite+version combination. Servers are fine because
they can theoretically select based on version (except in practice OpenSSL doesn't support that).

If that wasn't enough there's another complication. For TLS v1.2 you have to
restrict the supported signature algorithms to exclude SHA1, allowing only
SHA256 and above. There is no way to do that in OpenSSL 1.0.1 clients.
Similarly the supported EC curves have to be restricted to exclude some which are
of insufficient field size.

In summary: it's a bloody mess.

The list of allowable ciphers for all versions of TLS, 1.0/1/1/1.2 is 'TLSv1.2:kRSA'
which includes those with no encryption or no authentication which are generally
undesirable and should be excluded. In full with explicit "+FIPS" qualification that becomes:
<pre>
'TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL'
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256
ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
</pre>
What does this ciphersuite specification mean in practice?

If the peer supports TLS v1.2 it will use a TLS v1.2 ciphersuite which is FIPS
186-4 compliant (with the curve and signature restrictions I mentioned) or
non-PFS RSA otherwise.

If the peer only supports TLS 1.1 or 1.0 it will fall back to the non-PFS RSA
ciphersuites which again will be FIPS 186-4 compliant subject to the silly key
and certificate signing restrictions.

The ciphersuite (for 1.0.1f+) of 'TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL'
will satisfy FIPS 186-4 for any version of TLS 1.0/1.1/1.2 with caveats as noted.

To specify a list of allowable ciphers for TLS 1.0/1.1 only append !TLSv1.2 which permanently deletes
those which are only usable for TLS v1.2, giving 'kRSA+FIPS:!TLSv1.2'.

=== Cipherstrings ===

Commentary on what the cipherstrings components mean and their relevance:

"TLSv1.2": list of ciphersuites only allowed for TLS 1.2. This means if TLS 1.2
is negotiated they can be used and if not they won't. They also happen to be
permitted by FIPS 186-4 because TLS 1.2 can use signature algorithms stronger
that SHA1. That means that it is "safe" to include this in a cipher string
because (a) they are compliant with FIPS 186-4 in for TLS 1.2 and (b) they can
never be used for TLS 1.1 or 1.0.

"kRSA": list of ciphersuites which support RSA key exchange. Because TLS 1.1 and
1.0 can only use SHA1+MD5 in signatures these are the only ones allowed because
they don't use signatures.

"FIPS": list of ciphersuites allowed in FIPS mode excluding those offering no
encryption. This is for informational purposes only because if you *are* in FIPS
mode you can only use those ciphersuites anyway (but including the no encryption
ones).

The lists above all include ciphersuites which you wouldn't normally use: no
encryption or no authentication. So those need to be disabled. This is done by
appending '!eNULL:!aNULL': this means "disable any ciphersuites present which
include no encryption or authentication".

So combining these we get the following cipher string in FIPS mode:
<pre>
'TLSv1.2:kRSA:!eNULL:!aNULL'
</pre>
which with the functionally redundant "+FIPS" qualifiers is equivant to:
<pre>
'TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL'
</pre>
Without the "+FIPS" qualifiers and outside FIPS mode you'll will see weak export grade
ciphersuites which would be disabled in FIPS mode. Those can be seen with:
<pre>
openssl ciphers -v 'TLSv1.2:kRSA:!eNULL:!aNULL'
</pre>
To see the actual set of ciphersuites in FIPS mode, without the explicit "+FIPS" qualifiers,
do:
<pre>
OPENSSL_FIPS=1 openssl ciphers -v 'TLSv1.2:kRSA:!eNULL:!aNULL'
</pre>
So in summary "in FIPS mode use the cipherstring 'TLSv1.2:kRSA:!eNULL:!aNULL'"

Note this important disclaimer though: This cipherstring *only* restricts the ciphersuites to those
not explicitly excluded by FIPS 186-4. There are other conditions which must be
enforced such as key size, permitted curves and permitted signature algorithms.
Just because a ciphersuite has been negotiated in this range does not guaranteed
compliance.

The "FIPS capable" OpenSSL does not currently provide a means to automatically enforce the
new FIPS 186-4 restrictions.

=== A quick overview of TLS ===

The primary purpose of the handshake is to enable both peers to securely obtain
a shared secret value called the pre-master secret. They then use that to
generate session keys (encryption and MAC) which are used for the exchange of
actual application data. The handshake is the only place public key algorithms
are used.

In the case of PFS ciphersuites both ends generate a temporary key (ECDH or DH)
and exchange the public bits with each other. They use the algorithm to generate
the shared DH/ECDH secret value which is used later on. The new FIPS restrictions interfere with
this because those keys have to be large enough. For ECDH an extension can be
used to ensure this. For DH you just have to hope the server has a big enough
key and abort if not.

For anonymous algorithms that's all you get. They are vulnerable to man in the
middle (MitM) attacks and so are rarely used.

In the real world algorithms include authentication. In those the server digitally
signs its ECDH or DH key using the key in its certificate. This is to ensure the
temporary ECDH or DH key can't be forged. It is that digital signature that is
important here and the one which the new FIPS restrictions disrupt.

How that temporary key is signed depends on the cipher suite and the key in the
server's certificate. The whole process is called server authentication.

In the case of TLS 1.0 and 1.1 that signature uses a MD5+SHA1 hybrid for RSA
keys and just SHA1 for DSA and ECDSA. That's why PFS is prohibited by the new FIPS
rules: there is no option but to use SHA1.

In the case of TLS 1.2 any valid combination can be used and the MD5+SHA1 hybrid is no
longer present for RSA. RSA just uses the same signature format that
certificates use (PKCS#1).

For TLS 1.2 the client sends the set of signature algorithms it supports in
preference order in the supported signature algorithms extensions. The server
then selects one and uses that for that signature. For new FIPS it would just
use SHA256 as a minimum or abort the connection if the client only supported
SHA1 (unlikely).

Client authentication in TLS is a secondary concern. In this case the client
signs some data related to the handshake and sends the result back. The server
then checks that signature.

As with server authentication TLS 1.1/1.0 has to use either MD5+SHA1 for RSA or
just SHA1 for other algorithms. So client authentication violates the new FIPS
restrictions and cannot be used for TLs 1.0/1.1.

TLS 1.2 removes the restriction to SHA1. In this case the server sends back the
algorithms it supports and the client selects one. Again SHA256 or
better s needed to comply with new FIPS restrictions.

Next consider the non-PFS case. We consider RSA
key exchange only as is the only practical option. This is completely different from PFS. In
this case the client generates the pre master secret and encrypts it using the
servers key. The server decrypts it and then uses that to complete the
handshake. No additional signing is used here so no place for SHA1 to be used.
The server is authenticated because if it didn't have the right key it couldn't
decrypt the pre-master secret. It's a bit unusual in that authentication (which
is normally associated with signatures) is performed using an RSA decryption
operation.

Some further discussion in case that wasn't confusing enough:

Some people say that it is implied that TLS 1.1 and 1.0 must use SHA1 in
digital signatures in all certificates. If so then
TLS 1.1 and 1.0 can never be compliant with new FIPS.

Assuming that is not true, what does it mean in practice? A
a public webserver would require a certificate signed by CAs that
use SHA256 minimum and large enough keys. Not a trivial
task in itself.

Aside from that, problems will be encountered if your server needs to use anything
outside of the new FIPS restrictions (e.g. to talk to other
clients). Some older browsers (e.g. IE on XP is one which is
still very common) don't support SHA2 at all. So they'll fail when they talk to
that server because the can't verify the signatures.

TLS 1.2 is a bit better, at least in theory. The supported signatures should apply to the
whole certificate chain. So a client advertising only SHA1+RSA receive a
chain supporting SHA1+RSA only (if the server has one) and a client supporting SHA256+RSA
will receive a "new FIPS" friendly chain.

However, in practice that requirement is generally ignored and implementations serve up whatever
chain is configured regardless of signature algorithms sent by the client
because many implementers consider that a slly restriction. For interoperability OpenSSL is
similarly lax if a "strict" option isn't set. In fact configuring multiple
chains like that can't be directly done in OpenSSL without application support
which nothing other than s_server can currently handle.

==== Digests in TLS ====

There are different purposes that digest algorithms are put to.

In TLS 1.2 something called the supported signature algorithms extension
determines the supported digests as a public key + algorithm pair. It's that
usage that FIPS 186-4 (and SP800-57) has an impact on. So you can't use RSA+SHA1
any more. For digital signatures the strength of SHA1 is at most 80 bits: it can
be less with a weak key.

That digital signature is used to maintain the integrity of the handshake
messages and certificate chains in PFS ciphersuites: basically server and client
authentication.

For TLS 1.2 you can specify any digest to be used to maintain handshake
integrity for digital signatures: for TLS 1.1 and below you could only use
SHA1+MD5. It's that reason why PFS ciphersuites are banned in TLS 1.1 and below.

Digests use HMAC. For HMAC use the key strength is the digest length so SHA1 is 160 bits.

Before TLS 1.2 all cipher suites used SHA1 HMAC (or in legacy cases MD5) for the
HMAC.

TLS 1.2 introduced some ciphersuites which used SHA256 and SHA384 for the HMAC
and the AEAD ones like AES-GCM which have a mac as part of the algorithm itself.

Note that TLS 1.2 also permits all the ciphersuites for TLS 1.1, 1.0 too.
For details see Table 2 and 3 in SP800-57.

Those tables make a lot more sense when you realise for digital signatures it's
half the digest size. So SHA1 is 20 bytes which is 160 bits and so 80 bits of
strength so it only appears in the "80 bits" box for digital signatures. Whereas
for other uses it is the full digest size so SHA1 appears in the 80, 112 and 128
bit boxes.

Unfortunately the FIPS terminology unnecessarily obfuscated the issue. It would
have been easier to just say in SP800-57 that SHA1 HMAC is 160 bits
of equivalent security instead of placing it in the :Security Strenght 128" row
of Table 3.

TLS 1.2 can use SHA1 in two different places. One is the signature algorithms on
certificates: i.e. the algorithm the CA signs with. The second place is
temporary key signature (server authentication) as described below.

==== Digital Signatures in TLS ====

There are three places digital signatures are used in TLS.

1. The signatures on certificates.

The certificates' signatures are set by the CA so to comply with new FIPS
whatever else you do you need a certificate chain that uses SHA256 at least.

2. Server Key Exchange.

The Server Key Exchange message contains a signature in any authenticated PFS
ciphersuite. The algorithm used depends on the version of TLS.

For TLS 1.1 and 1.0 the algorithm is either a MD5+SHA1 hybrid (RSA) or SHA1
(DSA, ECDSA). Both of these are prohibited by new FIPS so TLS 1.1 and 1.0
authenticated PFS ciphersuites are not allowed.

For TLS 1.2 any appropriate algorithm can be used to sign Server Key Exchange
messages. So PFS authenticated ciphersuites *are* allowed under new FIPS as long
as SHA1 is not used to sign Server Key Exchange. MD5 is of course a double no-no.

3. Certificate Verify.

The Certificate Verify message is used whenever client authentication is enabled
for any applicable ciphersuite (not just PFS). The same digest algorithms are
used as Server Key Exchange.

Therefore new FIPS and TLS 1.1 and 1.0 prohibits client authentication outright
in *any* ciphersuite.

TLS 1.2 is more flexible and can use any appropriate algorithm so client
authentication is permitted as long as SHA1 and MD5 are not used.

=== What about versions of OpenSSL prior to 1.0.1f? ===

The "TLSv1.2" ciphersuite designation was added at 1.0.1f. For earlier versions of
OpenSSL the current equivalent of the cipherstring
<pre>
'TLSv1.2:kRSA:!eNULL:!aNULL'
</pre>
can be "brute forced" as the unwieldy
<pre>
'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:ADH-AES256-GCM-SHA384:ADH-AES256-SHA256:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:AES256-GCM-SHA384:AES256-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ADH-AES128-GCM-SHA256:ADH-AES128-SHA256:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:AES128-GCM-SHA256:AES128-SHA256:NULL-SHA256:kRSA:!eNULL:!aNULL'
</pre>
However, as new ciphersuites get added to the 'TLSv1.2' ciphersuite that brute force
equivalent might end up not being
equivalent any more.

Since TLSv1.2 only ciphers use SHA256, SHA384 and AES in GCM mode so one string is:
<pre>
'AESGCM:SHA384:SHA256'
</pre>
There are other ways to get the same effect. One is to disable any ciphers which
use SHA1. So "FIPS:-SHA" is currently equivalent to "FIPS+TLSv1.2". The use of
the "-SHA" is necessary here because it only *temporarily* disables SHA1 MACs.
That means you can do: "FIPS:-SHA:FIPS+kRSA" to add back the RSA key exchange
ciphersuites that use SHA1. Contrast that with using "!SHA" instead which permanently
removes SHA1 from the cipherstring.

Talk:FIPS Warnings and Cautions

2014-01-27T23:25:44Z

Stevem: add signature

==Distribution from Snail Mail CD==

"You must use a source distribution file from an official snail-mailed CD."

I understood it to be the case that you CAN download it, but if you do you MUST verify the HMAC-SHA-1 digest with an independantly validated FIPS 140-2 product. Getting access to such a product may be very difficult for most people!!

Yes, difficult approximating impossible ... see the discussion in Section 6.6 of the [https://www.openssl.org/docs/fips/UserGuide-2.0.pdf FIPS Module User Guide]. That discussion summarizes an extensive dialog with the CMVP during which it became clear that no unassailably correct "download" solution was possible (at least for the OpenSSL FIPS Object Module which is held to a different standard than other validations).--[[User:Stevem|Stevem]] 23:25, 27 January 2014 (UTC)

Talk:FIPS Warnings and Cautions

2014-01-27T23:25:06Z

Stevem: /* Distribution from Snail Mail CD */

FIPS Warnings and Cautions

2014-01-27T20:59:07Z

Stevem: Summary list of major gotchas

Software developers are the primary audience of this wiki, and as such naturally tend to focus on technical issues. When told to look into this thing called a "FIPS 140-2 validated module", the developer will focus on questions like: How do I build the FIPS module for this platform? How do I code my application to use it?

This wiki will attempt to address those questions, but there is a huge danger there. There is one and only one reason to use the OpenSSL FIPS Object Module, or the associated "FIPS capable" OpenSSL: because a non-technical ''policy'' specifically requires it. There is no advantage to using the FIPS module in any other circumstance; the cryptographic services proviced by the FIPS module are necessarily less secure, less maintainable, and have worse performance than those provided by an OpenSSL release of equal or later vintage. The FIPS module is used only because a specific customer or situation requires it, most commonly the U.S. Government and Department of Defense where procurement policies require that cryptographic implementations be FIPS 140-2 validated.

However, there is a lot more to satisfying those policy mandates than just getting the software to compile and run for your specific platform. FIPS 140-2 also imposes a number of what can be called ideological requirements that have no technical or practical basis and are not obvious or comprehensible to the typical software developer. The mere fact that a FIPS module (and/or FIPS capable OpenSSL) is running on a given platform does ''not'' mean that the result can be claimed as FIPS 140-2 validated.

The most obvious example is the requirement that the source code distribution be obtained from a snail-mailed CD and not downloaded from [http://www.openssl.org/source/ http://www.openssl.org/source/]. That is true even though a cursory check will show both files to be bit-for-bit identical. A software developer thinks of bits as fungible and interchangeable, like electrons in a wire or drops of water in an ocean; a file (string of bits) copied or moved to another location is the same file. In the world of FIPS 140-2 they are not; the file copied from anywhere than the physical CD is not the same even though it is bit-for-bit identical. The world of FIPS 140-2 contains several such concepts that are incomprehensible to the uninitiated, and sometimes the topic of much discussion and disagreement among the test labs and specialists that work in that world extensively.

The purpose of this page is to present a warning that simply getting the FIPS module to compile and run for your platform(s) of interest is the least of your problems, as you need to satisfy the ideological requirements. That's the hard part, as those requirements are nowhere articulated clearly.

This page will be linked where appropriate using the following icon: {{FIPS}}

Summary of major pitfalls (some of which can't easily be summarized and all of which need more detailed discussion):

:* You ''must'' use a source distribution file from an [http://opensslfoundation.com/fips/verify.html official snail-mailed CD].
:* Your target platform must be "close enough" to one of the formally tested platforms.
:* You cannot modify the contents of the source distribution file ''at all''.
:* Your build environment must be "close enough" to the one documented for the formal testing.

{{TODO|This is incomplete}}

Template:FIPS

2014-01-27T20:27:20Z

Stevem: New template

{|
| bgcolor="red" | [[File:Skull_and_crossbones.svg|50px|link=FIPS:FIPS Warnings and Cautions]]
| <span style="color:red"> Important FIPS Warnings </span>
|}

<includeonly>[[Category: FIPS]]</includeonly>

FIPS Warnings and Cautions

2014-01-27T19:27:22Z

Stevem: red in warning logo

Software developers are the primary audience of this wiki, and as such naturally tend to focus on technical issues. When told to look into this thing called a "FIPS 140-2 validated module", the developer will focus on questions like: How do I build the FIPS module for this platform? How do I code my application to use it?

This wiki will attempt to address those questions, but there is a huge danger there. There is one and only one reason to use the OpenSSL FIPS Object Module, or the associated "FIPS capable" OpenSSL: because a non-technical ''policy'' specifically requires it. There is no advantage to using the FIPS module in any other circumstance; the cryptographic services proviced by the FIPS module are necessarily less secure, less maintainable, and have worse performance than those provided by an OpenSSL release of equal or later vintage. The FIPS module is used only because a specific customer or situation requires it, most commonly the U.S. Government and Department of Defense where procurement policies require that cryptographic implementations be FIPS 140-2 validated.

However, there is a lot more to satisfying those policy mandates than just getting the software to compile and run for your specific platform. FIPS 140-2 also imposes a number of what can be called ideological requirements that have no technical or practical basis and are not obvious or comprehensible to the typical software developer. The mere fact that a FIPS module (and/or FIPS capable OpenSSL) is running on a given platform does ''not'' mean that the result can be claimed as FIPS 140-2 validated.

The most obvious example is the requirement that the source code distribution be obtained from a snail-mailed CD and not downloaded from [http://www.openssl.org/source/ http://www.openssl.org/source/]. That is true even though a cursory check will show both files to be bit-for-bit identical. A software developer thinks of bits as fungible and interchangeable, like electrons in a wire or drops of water in an ocean; a file (string of bits) copied or moved to another location is the same file. In the world of FIPS 140-2 they are not; the file copied from anywhere than the physical CD is not the same even though it is bit-for-bit identical. The world of FIPS 140-2 contains several such concepts that are incomprehensible to the uninitiated, and sometimes the topic of much discussion and disagreement among the test labs and specialists that work in that world extensively.

The purpose of this page is to present a warning that simply getting the FIPS module to compile and run for your platform(s) of interest is the least of your problems, as you need to satisfy the ideological requirements. That's the hard part, as those requirements are nowhere articulated clearly.

This page will be linked where appropriate using the following icon:

{|
| bgcolor="red" | [[File:Skull_and_crossbones.svg|50px|link=FIPS:FIPS Warnings and Cautions]]
| <span style="color:red"> Important FIPS Warnings </span>
|}

[more to come]

FIPS Warnings and Cautions

2014-01-27T19:12:45Z

Stevem: first try at FIPS warnings icon

Software developers are the primary audience of this wiki, and as such naturally tend to focus on technical issues. When told to look into this thing called a "FIPS 140-2 validated module", the developer will focus on questions like: How do I build the FIPS module for this platform? How do I code my application to use it?

This wiki will attempt to address those questions, but there is a huge danger there. There is one and only one reason to use the OpenSSL FIPS Object Module, or the associated "FIPS capable" OpenSSL: because a non-technical ''policy'' specifically requires it. There is no advantage to using the FIPS module in any other circumstance; the cryptographic services proviced by the FIPS module are necessarily less secure, less maintainable, and have worse performance than those provided by an OpenSSL release of equal or later vintage. The FIPS module is used only because a specific customer or situation requires it, most commonly the U.S. Government and Department of Defense where procurement policies require that cryptographic implementations be FIPS 140-2 validated.

However, there is a lot more to satisfying those policy mandates than just getting the software to compile and run for your specific platform. FIPS 140-2 also imposes a number of what can be called ideological requirements that have no technical or practical basis and are not obvious or comprehensible to the typical software developer. The mere fact that a FIPS module (and/or FIPS capable OpenSSL) is running on a given platform does ''not'' mean that the result can be claimed as FIPS 140-2 validated.

The most obvious example is the requirement that the source code distribution be obtained from a snail-mailed CD and not downloaded from [http://www.openssl.org/source/ http://www.openssl.org/source/]. That is true even though a cursory check will show both files to be bit-for-bit identical. A software developer thinks of bits as fungible and interchangeable, like electrons in a wire or drops of water in an ocean; a file (string of bits) copied or moved to another location is the same file. In the world of FIPS 140-2 they are not; the file copied from anywhere than the physical CD is not the same even though it is bit-for-bit identical. The world of FIPS 140-2 contains several such concepts that are incomprehensible to the uninitiated, and sometimes the topic of much discussion and disagreement among the test labs and specialists that work in that world extensively.

The purpose of this page is to present a warning that simply getting the FIPS module to compile and run for your platform(s) of interest is the least of your problems, as you need to satisfy the ideological requirements. That's the hard part, as those requirements are nowhere articulated clearly.

This page will be linked where appropriate using the following icon:

{| border="1"
|[[File:Skull_and_crossbones.svg|50px|link=FIPS:FIPS Warnings and Cautions]]
|Important FIPS Warnings
|}

[more to come]

File:Skull and crossbones.svg

2014-01-27T19:02:23Z

Stevem: logo for FIPS warnings

logo for FIPS warnings

FIPS Warnings and Cautions

2014-01-27T18:44:20Z

Stevem: moved FIPS Warnings and Cautions to FIPS:FIPS Warnings and Cautions: Create new namespace

FIPS Warnings and Cautions

2014-01-27T18:16:26Z

Stevem: initial content

Main Page

2014-01-27T17:44:07Z

Stevem: /* Usage and Programming */

If this is your first visit or to get an account please see the [[Welcome]] page. Your participation and [[Contributions]] are valued.

This wiki is intended as a place for collecting, organizing, and refining useful information about OpenSSL that is currently strewn among multiple locations and formats.

== OpenSSL Quick Links ==

<TABLE border=0>
<TR>
<TD>[[OpenSSL Overview]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Compilation and Installation]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Internals]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Mailing Lists]] </TD>
</TR>
<TR>
<TD>[[libcrypto API]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[libssl API]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Examples]] </TD>
</TR>
<TR>
<TD>[[License]] </TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Command Line Utilities]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Related Links]]</TD>
</TR>
</TABLE>

== Administrivia ==
Site guidelines, legal and admininstrative issues.
:* [[Basic rules]], [[Commercial Product Disclaimer]], [[Contributions]], [[Copyright]], [[License]]
:* Using This Wiki
:: [http://meta.wikimedia.org/wiki/Help:Contents Wiki User's Guide], [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list], [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ], [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki Mailing List]

== Reference ==
This section contains the automagically generated man pages from the OpenSSL git repository, and similar "man" style reference documentation. The man pages are automatically imported from the OpenSSL git repository and local wiki modifications are submitted as patches.
:* OpenSSL Manual Pages
::* [[Manual:Openssl(1)]], [[Manual:Ssl(3)]], [[Manual:Crypto(3)]], [[Documentation Index]]
:: If you wish to edit any of the Manual page content please refer to the [[Guidelines for Manual Page Authors]] page.
:* [[API]], [[Libcrypto API]], [[Libssl API]]
:* [[FIPS mode()]], [[FIPS_mode_set()]]

== Usage and Programming ==
This section has discussions of practical issues in using OpenSSL
:* Building from Source
:: Where to find it, the different versions, how to build and install it.
:* [[OpenSSL Overview]]
:* [[Versioning]]
:* [[Compilation and Installation]]
:* [[EVP]]
:: Programming techniques and example code
:: Use of EVP is preferred for most applications and circumstances
::* [[EVP Asymmetric Encryption and Decryption of an Envelope]]
::* [[EVP Authenticated Encryption and Decryption]]
::* [[EVP Symmetric Encryption and Decryption]]
::* [[EVP Key and Parameter Generation]]
::* [[EVP Key Agreement]]
::* [[EVP Message Digests]]
::* [[EVP Key Derivation]]
::* [[EVP Signing and Verifying|EVP Signing and Verifying (including MAC codes)]]
:* [[STACK API]]
:* Low Level APIs
:: More specialized non-EVP usage
::* [[Diffie-Hellman parameters]]
:* [[FIPS Mode]]

== Concepts and Theory ==
Discussions of basic cryptographic theory and concepts
Discussions of common operational issues
:* [[Base64]]
:* [[FIPS 140-2]]
:* [[Random Numbers]]
:* [[Diffie Hellman]]
:* [[Elliptic Curve Diffie Hellman]]
:* [[Elliptic Curve Cryptography]]

== Internals and Development ==
This section is for internal details of primary interest to OpenSSL maintainers and power users
:* [[Internals]]
:* [[Code Quality]]
:* [[Static and Dynamic Analysis]]
:* [[OCB|OCB Licence details]]

Main Page

2014-01-27T17:43:17Z

Stevem: /* Usage and Programming */

If this is your first visit or to get an account please see the [[Welcome]] page. Your participation and [[Contributions]] are valued.

This wiki is intended as a place for collecting, organizing, and refining useful information about OpenSSL that is currently strewn among multiple locations and formats.

== OpenSSL Quick Links ==

<TABLE border=0>
<TR>
<TD>[[OpenSSL Overview]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Compilation and Installation]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Internals]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Mailing Lists]] </TD>
</TR>
<TR>
<TD>[[libcrypto API]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[libssl API]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Examples]] </TD>
</TR>
<TR>
<TD>[[License]] </TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Command Line Utilities]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Related Links]]</TD>
</TR>
</TABLE>

== Administrivia ==
Site guidelines, legal and admininstrative issues.
:* [[Basic rules]], [[Commercial Product Disclaimer]], [[Contributions]], [[Copyright]], [[License]]
:* Using This Wiki
:: [http://meta.wikimedia.org/wiki/Help:Contents Wiki User's Guide], [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list], [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ], [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki Mailing List]

== Reference ==
This section contains the automagically generated man pages from the OpenSSL git repository, and similar "man" style reference documentation. The man pages are automatically imported from the OpenSSL git repository and local wiki modifications are submitted as patches.
:* OpenSSL Manual Pages
::* [[Manual:Openssl(1)]], [[Manual:Ssl(3)]], [[Manual:Crypto(3)]], [[Documentation Index]]
:: If you wish to edit any of the Manual page content please refer to the [[Guidelines for Manual Page Authors]] page.
:* [[API]], [[Libcrypto API]], [[Libssl API]]
:* [[FIPS mode()]], [[FIPS_mode_set()]]

== Usage and Programming ==
This section has discussions of practical issues in using OpenSSL
:* Building from Source
:: Where to find it, the different versions, how to build and install it.
:* [[OpenSSL Overview]]
:* [[Versioning]]
:* [[Compilation and Installation]]
:* [[EVP]]
:: Programming techniques and example code
:: Use of EVP is preferred for most applications and circumstances
::* [[EVP Asymmetric Encryption and Decryption of an Envelope]]
::* [[EVP Authenticated Encryption and Decryption]]
::* [[EVP Symmetric Encryption and Decryption]]
::* [[EVP Key and Parameter Generation]]
::* [[EVP Key Agreement]]
::* [[EVP Message Digests]]
::* [[EVP Key Derivation]]
::* [[EVP Signing and Verifying|EVP Signing and Verifying (including MAC codes)]]
:* [[STACK API]]
:* Low Level APIs
:: More specialized non-EVP usage
::* [[Diffie-Hellman parameters]]
:* [FIPS Mode]]

== Concepts and Theory ==
Discussions of basic cryptographic theory and concepts
Discussions of common operational issues
:* [[Base64]]
:* [[FIPS 140-2]]
:* [[Random Numbers]]
:* [[Diffie Hellman]]
:* [[Elliptic Curve Diffie Hellman]]
:* [[Elliptic Curve Cryptography]]

== Internals and Development ==
This section is for internal details of primary interest to OpenSSL maintainers and power users
:* [[Internals]]
:* [[Code Quality]]
:* [[Static and Dynamic Analysis]]
:* [[OCB|OCB Licence details]]

Main Page

2013-05-31T14:16:44Z

Stevem: New look, for better or worse

If this is your first visit please see the [[Welcome]] page. Your participation and [[Contributions]] are valued.

This wiki is intended as a place for collecting, organizing, and refining useful information about OpenSSL that is currently strewn among multiple locations and formats.

== OpenSSL Quick Links ==

<TABLE border=0>
<TR>
<TD>[[OpenSSL Overview]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Compilation and Installation]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Internals]]</TD>
</TR>
<TR>
<TD>[[libcrypto API]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[libssl API]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Examples]] </TD>
</TR>
<TR>
<TD>[[License]] </TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Command Line Utilities]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Related Links]]</TD>
</TR>
</TABLE>

== Administrivia ==
Site guidelines, legal and admininstrative issues.
:* [[Basic rules]], [[Commercial Product Disclaimer]], [[Contributions]], [[Copyright]], [[License]]
:* Using This Wiki
:: [http://meta.wikimedia.org/wiki/Help:Contents Wiki User's Guide], [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list], [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ], [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki Mailing List]

== Reference ==
This section contains the automagically generated man pages from the OpenSSL git repository, and similar "man" style reference documentation. The man pages are automatically imported from the OpenSSL git repository and local wiki modifications are submitted as patches.
:* OpenSSL Manual Pages
::* [[Manual:Openssl(1)]], [[Manual:Ssl(3)]], [[Manual:Crypto(3)]], [[Documentation Index]]
:: If you wish to edit any of the Manual page content please refer to the [[Guidelines for Manual Page Authors]] page.
:* [[API]], [[Libcrypto API]], [[Libssl API]]
:* [[FIPS mode()]], [[FIPS_mode_set()]]

== Usage and Programming ==
This section has discussions of practical issues in using OpenSSL
:* Building from Source
:: Where to find it, the different versions, how to build and install it.
:* [[OpenSSL Overview]]
:* [[Versioning]]
:* [[Compilation and Installation]]
:* EVP
:: Programming techniques and example code
:: Use of EVP is preferred for most applications and circumstances
::* [[EVP Asymmetric Encryption and Decryption of an Envelope]]
::* [[EVP Authenticated Encryption and Decryption]]
::* [[EVP Symmetric Encryption and Decryption]]
::* [[EVP Key and Parameter Generation]]
::* [[EVP Key Agreement]]
::* [[EVP Message Digests]]
::* [[EVP Key Derivation]]
::* [[EVP Signing and Verifying|EVP Signing and Verifying (including MAC codes)]]
:* Low Level APIs
:: More specialized non-EVP usage
::* [[Diffie-Hellman parameters]]

== Concepts and Theory ==
Discussions of basic cryptographic theory and concepts
Discussions of common operational issues
:* [[Base64]]
:* [[FIPS 140-2]]
:* [[Random Numbers]]
:* [[Diffie Hellman]]
:* [[Elliptic Curve Diffie Hellman]]
:* [[Elliptic Curve Cryptography]]

== Internals and Development ==
This section is for internal details of primary interest to OpenSSL maintainers and power users
:* [[Internals]]
:* [[Code Quality]]
:* [[Static and Dynamic Analysis]]

Talk:Main Page

2013-05-31T13:02:50Z

Stevem: More edits trying for that new look

Content Outline

== OpenSSL Quick Links ==

<TABLE border=0>
<TR>
<TD>[[OpenSSL Overview]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Compilation and Installation]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Internals]]</TD>
</TR>
<TR>
<TD>[[libcrypto API]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[libssl API]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Examples]] </TD>
</TR>
<TR>
<TD>[[License]] </TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Command Line Utilities]]</TD>
<TD>[[Image:HTAB.png]][[Image:HTAB.png]]</TD>
<TD>[[Related Links]]</TD>
</TR>
</TABLE>

== Administrivia ==
Site guidelines, legal and admininstrative issues.
:* [[Basic rules]], [[Commercial Product Disclaimer]], [[Contributions]], [[Copyright]], [[License]]
:* Using This Wiki
:: [http://meta.wikimedia.org/wiki/Help:Contents Wiki User's Guide], [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list], [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ], [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki Mailing List]

== Reference ==
This section contains the automagically generated man pages from the OpenSSL git repository, and similar "man" style reference documentation. The man pages are automatically imported from the OpenSSL git repository and local wiki modifications are submitted as patches.
:* OpenSSL Manual Pages
::* [[Manual:Openssl(1)]], [[Manual:Ssl(3)]], [[Manual:Crypto(3)]], [[Documentation Index]]
:: If you wish to edit any of the Manual page content please refer to the [[Guidelines for Manual Page Authors]] page.
:* [[API]], [[Libcrypto API]], [[Libssl API]]
:* [[FIPS mode()]], [[FIPS_mode_set()]]

== Usage and Programming ==
This section has discussions of practical issues in using OpenSSL
:* Building from Source
:: Where to find it, the different versions, how to build and install it.
:* [[OpenSSL Overview]]
:* [[Versioning]]
:* [[Compilation and Installation]]
:* EVP
:: Programming techniques and example code
:: Use of EVP is preferred for most applications and circumstances
::* [[EVP Asymmetric Encryption and Decryption of an Envelope]]
::* [[EVP Authenticated Encryption and Decryption]]
::* [[EVP Symmetric Encryption and Decryption]]
::* [[EVP Key and Parameter Generation]]
::* [[EVP Key Agreement]]
::* [[EVP Message Digests]]
::* [[EVP Key Derivation]]
::* [[EVP Signing and Verifying|EVP Signing and Verifying (including MAC codes)]]
:* Low Level APIs
:: More specialized non-EVP usage
::* [[Diffie-Hellman parameters]]

== Concepts and Theory ==
Discussions of basic cryptographic theory and concepts
Discussions of common operational issues
:* [[Base64]]
:* [[FIPS 140-2]]
:* [[Random Numbers]]
:* [[Diffie Hellman]]
:* [[Elliptic Curve Diffie Hellman]]
:* [[Elliptic Curve Cryptography]]

== Internals and Development ==
This section is for internal details of primary interest to OpenSSL maintainers and power users
:* [[Internals]]
:* [[Code Quality]]
:* [[Static and Dynamic Analysis]]

== Miscellanous ==
For the material that doesn't seem to fit anywhere else
:* New topics pending categorization (not yet linked elsewhere)
:* Incomplete or contentious pages under discussion

----
I like it - it brings the interesting content right up front. It probably needs to have some top and tail text to describe what this wiki is for, and how to contribute. I added a link to the Elliptic Curve Cryptography page above
--[[User:Matt|Matt]] 15:02, 30 May 2013 (UTC)

Talk:Main Page

2013-05-31T12:55:06Z

Stevem: Reference guidelines

Content Outline

== Administrivia ==
Site guidelines, legal and admininstrative issues.
:* [[Basic rules]], [[Commercial Product Disclaimer]], [[Contributions]], [[Copyright]], [[License]]

== Reference ==
This section contains the automagically generated man pages from the OpenSSL git repository, and similar "man" style reference documentation. The man pages are automatically imported from the OpenSSL git repository and local wiki modifications are submitted as patches.
:* OpenSSL Manual Pages
::* [[Manual:Openssl(1)]], [[Manual:Ssl(3)]], [[Manual:Crypto(3)]], [[Documentation Index]]
:: If you wish to edit any of the Manual page content please refer to the [[Guidelines for Manual Page Authors]] page.
:* [[API]], [[Libcrypto API]], [[Libssl API]]
:* [[FIPS mode()]], [[FIPS_mode_set()]]

== Usage and Programming ==
This section has discussions of practical issues in using OpenSSL
:* Building from Source
:: Where to find it, the different versions, how to build and install it.
:* [[OpenSSL Overview]]
:* [[Versioning]]
:* [[Compilation and Installation]]
:* EVP
:: Programming techniques and example code
:: Use of EVP is preferred for most applications and circumstances
::* [[EVP Asymmetric Encryption and Decryption of an Envelope]]
::* [[EVP Authenticated Encryption and Decryption]]
::* [[EVP Symmetric Encryption and Decryption]]
::* [[EVP Key and Parameter Generation]]
::* [[EVP Key Agreement]]
::* [[EVP Message Digests]]
::* [[EVP Key Derivation]]
::* [[EVP Signing and Verifying|EVP Signing and Verifying (including MAC codes)]]
:* Low Level APIs
:: More specialized non-EVP usage
::* [[Diffie-Hellman parameters]]

== Concepts and Theory ==
Discussions of basic cryptographic theory and concepts
Discussions of common operational issues
:* [[Base64]]
:* [[FIPS 140-2]]
:* [[Random Numbers]]
:* [[Diffie Hellman]]
:* [[Elliptic Curve Diffie Hellman]]
:* [[Elliptic Curve Cryptography]]

== Internals and Development ==
This section is for internal details of primary interest to OpenSSL maintainers and power users
:* [[Internals]]
:* [[Code Quality]]
:* [[Static and Dynamic Analysis]]

== Miscellanous ==
For the material that doesn't seem to fit anywhere else
:* New topics pending categorization (not yet linked elsewhere)
:* Incomplete or contentious pages under discussion

----
I like it - it brings the interesting content right up front. It probably needs to have some top and tail text to describe what this wiki is for, and how to contribute. I added a link to the Elliptic Curve Cryptography page above
--[[User:Matt|Matt]] 15:02, 30 May 2013 (UTC)

Talk:Main Page

2013-05-30T17:59:49Z

Stevem: Update with section headers

Content Outline

== Administrivia ==
Site guidelines, legal and admininstrative issues.
:* [[Basic rules]], [[Commercial Product Disclaimer]], [[Contributions]], [[Copyright]], [[License]]

== Reference ==
This section contains the automagically generated man pages from the OpenSSL git repository, and similar "man" style reference documentation. The man pages are automatically imported from the OpenSSL git repository and local wiki modifications are submitted as patches.
:* OpenSSL Manual Pages
:* [[Manual:Openssl(1)]], [[Manual:Ssl(3)]], [[Manual:Crypto(3)]], [[Documentation Index]]
:* [[API]], [[Libcrypto API]], [[Libssl API]]
:* [[FIPS mode()]], [[FIPS_mode_set()]]

== Usage and Programming ==
This section has discussions of practical issues in using OpenSSL
:* Building from Source
:: Where to find it, the different versions, how to build and install it.
:* [[OpenSSL Overview]]
:* [[Versioning]]
:* [[Compilation and Installation]]
:* EVP
:: Programming techniques and example code
:: Use of EVP is preferred for most applications and circumstances
::* [[EVP Asymmetric Encryption and Decryption of an Envelope]]
::* [[EVP Authenticated Encryption and Decryption]]
::* [[EVP Symmetric Encryption and Decryption]]
::* [[EVP Key and Parameter Generation]]
::* [[EVP Key Agreement]]
::* [[EVP Message Digests]]
::* [[EVP Key Derivation]]
::* [[EVP Signing and Verifying]]
:* Low Level APIs
:: More specialized non-EVP usage
::* [[Diffie-Hellman parameters]]

== Concepts and Theory ==
Discussions of basic cryptographic theory and concepts
Discussions of common operational issues
:* [[Base64]]
:* [[FIPS 140-2]]
:* [[Random Numbers]]
:* [[Diffie Hellman]]
:* [[Elliptic Curve Diffie Hellman]]
:* [[Elliptic Curve Cryptography]]

== Internals and Development ==
This section is for internal details of primary interest to OpenSSL maintainers and power users
:* [[Internals]]
:* [[Code Quality]]
:* [[Static and Dynamic Analysis]]

== Miscellanous ==
For the material that doesn't seem to fit anywhere else
:* New topics pending categorization (not yet linked elsewhere)
:* Incomplete or contentious pages under discussion

----
I like it - it brings the interesting content right up front. It probably needs to have some top and tail text to describe what this wiki is for, and how to contribute. I added a link to the Elliptic Curve Cryptography page above
--[[User:Matt|Matt]] 15:02, 30 May 2013 (UTC)

Main Page

2013-05-30T17:26:18Z

Stevem: Relocate welcome information to separate page

Welcome

2013-05-30T17:17:47Z

Stevem: New page, offloaded from main page

'''Welcome to the OpenSSL Wiki'''

This wiki is under construction as we figure out what works and what doesn't. Please see the [[basic rules]] which are summarized here:

This wiki is intended for the OpenSSL community. There are a few minor restrictions so we don't have to fool with capchas and constantly monitor for spam, defacements, and vandalism. The essence of the restrictions are:

* Everyone can read content
* Approved registered users can add or edit content

We encourage your participation and hope you will add pages and improve existing pages. If you want to add or edit content you should request an account by sending an email to wiki-admin@opensslfoundation.com and give a sentence or two describing your interest in OpenSSL so that we know that you are not a spammer!!

We hope to have multiple administrators. Those who have an interest may request admission to the Administrator or Bureaucrat groups.

We would like the content to be as accessible and usable as possible. All contributions must be made available under the current OpenSSL licence (and any future OpenSSL license) as described on the [[License]] page. We understand existing OpenSSL subject matter from other sources will inevitably appear here. Please respect copyright restrictions, and only place material here if it is already under the OpenSSL license or if you are the copyright holder and release it under the current and future OpenSSL license, or it is currently in the public domain.

It remains to be seen how this will work out. If you think your contributions have been blocked or modified inappropriately it was probably done by accident; please contact Steve Marquess, marquess@opensslfoundation.com, +1 301-874-2571.

Talk:Main Page

2013-05-30T13:39:04Z

Stevem: First draft

This [[Main Page]] really needs some work. Here are some initial thoughts on an overall organization:

* Administrivia
: Site guidelines, legal and admininstrative issues.
** [[Basic rules]], [[Commercial Product Disclaimer]], [[Contributions]], [[Copyright]], [[License]]

* Reference
: This section has the automagically generated man pages from the OpenSSL git repository, and similar "man" style reference documentation
** OpenSSL Manual Pages
*** [[Manual:Openssl(1)]], [[Manual:Ssl(3)]], [[Manual:Crypto(3)]], [[Documentation Index]]
** [[API]], [[Libcrypto API]], [[Libssl API]]
** [[FIPS mode()]], [[FIPS_mode_set()]]

* Usage (or Programming?)
: This section has discussions of practical issues in using OpenSSL
** Building from Source
** [[OpenSSL Overview]]
** [[Versioning]]
** [[Compilation and Installation]]
** EVP
:: Programming techniques and example code
:: Use of EVP is preferred for most applications and circumstances
*** [[EVP Asymmetric Encryption and Decryption of an Envelope]]
*** [[EVP Authenticated Encryption and Decryption]]
*** [[EVP Symmetric Encryption and Decryption]]
*** [[EVP Key and Parameter Generation]]
*** [[EVP Key Agreement]]
*** [[EVP Message Digests]]
*** [[EVP Key Derivation]]
*** [[EVP Signing and Verifying]]
** Low Level APIs
:: More specialized non-EVP usage
*** [[Diffie-Hellman parameters]]

* Concepts and Theory
: Discussions of basic cryptographic theory and concepts
: Discussions of common operational issues
** [[Base64]]
** [[FIPS 140-2]]
** [[Random Numbers]]
** [[Diffie Hellman]]
** [[Elliptic Curve Diffie Hellman]]

* Internals and Development
: This section is for internal details of primary interest to OpenSSL maintainers and power users
** [[Internals]]
** [[Code Quality]]
** [[Static and Dynamic Analysis]]

* Miscellanous

FIPS Build Guidelines

2013-05-30T13:03:47Z

Stevem: Intro sentence

This section covers some of the common issues and questions with building and using the FIPS 140-2 validated OpenSSL FIPS Object Module.

=== FIPS Module Build ===

The FIPS module is the binary file fipscanister.o (fipscanister.lib for Windows) created by the build process.
(Technically speaking the FIPS module also includes the companion fipscanister.o.sha1,fips_premain.c, and fips_premain.c.sha1 files).

The [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf Security Policy] document defines a very specific procedure for creating a binary FIPS module from the official source distributions:

gunzip -c openssl-fips-2.0.''N''.tar.gz | tar xf -
cd openssl-fips-2.0.''N''
./config
make

(for Unix/Linux). The Security Policy and [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 NIST CMVP web site entry] also clearly state that the source distribution (tarball) ''cannot'' be modified, ''at all''. The unofficial [http://www.openssl.org/docs/fips/UserGuide-2.0.pdf FIPS user Guide] also notes this restriction.

That is worth repeating as the question appears repeatedly: you '''cannot modify the contents of the official tarball'''. The CMVP has imposed that very specific prohibition on all of the OpenSSL FIPS Object Module validations. From the software developer/engineer perspective that prohibition is senseless and furstrating, but it is what it is. You can't modify the tarball, even if the tiniest tweak would make the difference between success and failure in building the module for your platform of interest. The natural tendency of a software developer is to identify and implement the simplest and most elegant modification to fix a build or execution. That approach generally won't work when the goal is to claim FIPS 140-2 validated status for the resulting module.

----
Question: Okay, got it. The official canonical build commands given above must be used with an unmodified official tarball. The end result doesn't build a usable module for my platform of interest. Is there ''anything'' I ''can'' do?
----

Answer: Maybe.

The CMVP has provided specific guidance on some things that ''must'' be done (e.g. the canonical build commands) and some things that ''cannot'' be done (modification of the tarball contents). However, based on an extensive series of validations of specific platforms (Operational Environments in FIPS-speak) we can discern some general rules for a limited set of techniques that are presumptively permissible.

==== Environment scripts ====

The ./config command determines a build target from various inputs, for example the ''uname'' command for Unix/Linux systems for native compilation. For cross-compilation the target characteristics are determined from environment variables MACHINE, SYSTEM, RELEASE, etc. The use of a shell script that sets the appropriate environment variables is well established. For instance [http://opensslfoundation.com/fips/2.0/platforms/android/setenv-android-4.1.sh http://opensslfoundation.com/fips/2.0/platforms/android/setenv-android-4.1.sh]:

#!/bin/sh
# Cross-compile environment for Android on ARMv7
#
# This script assumes the Android NDK and the OpenSSL FIPS
# tarballs have been unpacked in the same directory

#android-sdk-linux/platforms Edit this to wherever you unpacked the NDK

if [ -d android-ndk-r8b ]; then
export ANDROID_NDK=$PWD/android-ndk-r8b
fi
if [ -d android-ndk-r8c ]; then
export ANDROID_NDK=$PWD/android-ndk-r8c
fi

# Edit to reference the incore script (usually in ./util/)
export FIPS_SIG=$PWD/openssl-fips-2.0.2/util/incore

for i in linux darwin
do
if [ -d $ANDROID_NDK/toolchains/arm-linux-androideabi-4.6/prebuilt/$i-x86/bin ]; then
PATH=$ANDROID_NDK/toolchains/arm-linux-androideabi-4.6/prebuilt/$i-x86/bin:$PATH
fi
done

export PATH

#
# Shouldn't need to edit anything past here.
#

export MACHINE=armv7l
export RELEASE=2.6.37
export SYSTEM=android
export ARCH=arm
export CROSS_COMPILE="arm-linux-androideabi-"
export ANDROID_DEV="$ANDROID_NDK/platforms/android-14/arch-arm/usr"
export HOSTCC=gcc

So in general specification of information needed to define the cross-compilation target for the toolkit is premissible, provided that the contents of the original official tarball are not modified.

==== Build Utilities ====

Multiple validated platforms have also been cross-compiled with build utilities supplied and residing outside of the official source distribution workarea, e.g. [http://opensslfoundation.com/fips/2.0/platforms/ios/setenv-ios-11.sh http://opensslfoundation.com/fips/2.0/platforms/ios/setenv-ios-11.sh] which contains:

# FIPS_SIG is the tool for determining the incore fingerprint
#export FIPS_SIG=/usr/local/ssl/fingerprint-macho
export FIPS_SIG="`pwd`"/iOS/incore_macho

The "incore" utilties (''incore, incore6x, msincore, incore_macho'') calculate and insert the [[incore digest]] of the executable file linked with the FIPS module, and are not used during creation of the actual FIPS module proper (''fipscanister.o'', ''fipscanister.lib''). Note most openssl-fips-2.0.N.tar.gz tarballs contain one or more incore utilities; these ''cannot be modified'' in place. However, specification of separate utility files residing ''outside'' of the unpacked tarball is permissible.

==== No-Nos ====

Some build environment modifications are known to be disallowed.

===== Code Path =====

The [[code path]] is an important concept. Modifications to the build environment that change the code path of the resulting binary code (e.g. adding/removing assembler optimizations, or changing between 32 and 64 bit code generation) mean that the original formally tested platform is no longer relevant.

==== Grey Areas ====

[TBD]

==== Conclusion ====

Some limited modifications to the build environment are permissible provided that:

* the contents of the official tarball are not modified, at all
* the canonical build commands are used (''gunzip ...; cd ...; ./config; make'')
* the code path is the same as for a formally tested platform

=== Application Linking ===

Ok, if you created the FIPS module (the fipscanister.lib and technically also the fipscanister.lib.sha1, fips_premain.c, fips_premain.c.sha1 files) *exactly* as documented in the Security Policy and without *any* modification of the ./openssl-fips-2.0.3/ workarea, *then* you have a FIPS module you can claim as FIPS 140-2 validated.

Having achieved that the next step is to link that FIPS module into an executable application. Here the restrictions are far less severe; consisting essentially of two responsibilities:

1) Verify the digests of the FIPS module (fipscanister.o, fips_premain.c) against the *.sha1 files.

2) Set the integrity test digest. The fipsld utility does than for native compiled, and an "incore" utility for cross-compilation. Different "incore" utilities are used for various cross-compiled platforms.

Note the CMVP does not (to our knowledge) impose any specific requirement on the "fipsld" or "incore" utilities. While it can be very dangerous to presume an understanding of their thought processes, as they see FIPS 140-2 validation from a very different perspective than the typical software developer/engineer, I believe it goes something like this:

The integrity digest is verified at runtime as part of the mandated POST (Power Up Self Test, a key FIPS 140-2 concept). The code that performs that check is carefully and formally reviewed and tested. That integrity test consists of calculating a HMAC-SHA1 digest of the TXT and RODATA segments of the FIPS module as mapped in live memory, and comparing it against a known value embedded in the module. The "fipsld" or "incore" utility stores that known value. No formal testing is required for that utility because for any given fixed string of bits (i.e. the TXT+RODATA segments) there is only one possible correct value for the HMAC-SHA1 digest. If an untested and defective fipsld/incore utility stores an incorrect value then the POST will fail, therefore only the latter need be formally tested.

FIPS Build Guidelines

2013-05-29T17:58:58Z

Stevem: s#incore#fipsld/incore#g in "Application Linking"

=== FIPS Module Build ===

The FIPS module is the binary file fipscanister.o (fipscanister.lib for Windows)
<ref>Technically speaking the FIPS module alsi includes the companion fipscanister.o.sha1,fips_premain.c, and fips_premain.c.sha1 files.
</ref>
created by the build process.

The [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf Security Policy] document defines a very specific procedure for creating a binary FIPS module from the official source distributions:

gunzip -c openssl-fips-2.0.''N''.tar.gz | tar xf -
cd openssl-fips-2.0.''N''
./config
make

(for Unix/Linux). The Security Policy and [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 NIST CMVP web site entry] also clearly state that the source distribution (tarball) ''cannot'' be modified, ''at all''. The unofficial [http://www.openssl.org/docs/fips/UserGuide-2.0.pdf FIPS user Guide] also notes this reestriction.

That is worth repeating as the question appears repeatedly: you '''cannot modify the contents of the official tarball'''. The CMVP has imposed that very specific prohibition on all of the OpenSSL FIPS Object Module validations. From the software developer/engineer perspective that prohibition is senseless and furstrating, but it is what it is. You can't modify the tarball, even if the tinest tweak would make the difference between success and failure in building the module for your platform of interest. The natural tendency of a software developer is to identify and implement the simplest and most elegant modification to fix a build or execution. That approach generally won't work when the goal is to claim FIPS 140-2 validated status for the resulting module.

----
Question: Okay, got it. The official canonical build commands given above must be used with an unmodified official tarball. The end result doesn't build a usable module for my platform if interest. Is there ''anything'' I ''can'' do?
----

Answer: Maybe.

The CMVP has provided specific guidance on some things that ''must'' be done (e.g. the canonical build commands) and some things that ''cannot'' be done (modification of the tarball contents). However, based on an extensive series of validations of specific platforms (Operational Environments in FIPS-speak) we can discern some general rules for a limited set of techniques that are presumptively permissible.

==== Environment scripts ====

The ./config command determines a build target from various inputs, for example the ''uname'' command for Unix/Linux systems for native compilation. For cross-compilation the target characteristics are determined from environment variables MACHINE, SYSTEM, RELEASE, etc. The use of a shell script that sets the appropriate environment variables is well established. For instance [http://opensslfoundation.com/fips/2.0/platforms/android/setenv-android-4.1.sh http://opensslfoundation.com/fips/2.0/platforms/android/setenv-android-4.1.sh]:

#!/bin/sh
# Cross-compile environment for Android on ARMv7
#
# This script assumes the Android NDK and the OpenSSL FIPS
# tarballs have been unpacked in the same directory

#android-sdk-linux/platforms Edit this to wherever you unpacked the NDK

if [ -d android-ndk-r8b ]; then
export ANDROID_NDK=$PWD/android-ndk-r8b
fi
if [ -d android-ndk-r8c ]; then
export ANDROID_NDK=$PWD/android-ndk-r8c
fi

# Edit to reference the incore script (usually in ./util/)
export FIPS_SIG=$PWD/openssl-fips-2.0.2/util/incore

for i in linux darwin
do
if [ -d $ANDROID_NDK/toolchains/arm-linux-androideabi-4.6/prebuilt/$i-x86/bin ]; then
PATH=$ANDROID_NDK/toolchains/arm-linux-androideabi-4.6/prebuilt/$i-x86/bin:$PATH
fi
done

export PATH

#
# Shouldn't need to edit anything past here.
#

export MACHINE=armv7l
export RELEASE=2.6.37
export SYSTEM=android
export ARCH=arm
export CROSS_COMPILE="arm-linux-androideabi-"
export ANDROID_DEV="$ANDROID_NDK/platforms/android-14/arch-arm/usr"
export HOSTCC=gcc

So in general specification of information needed to define the cross-compilation target for the toolkit is premissible, provided that the contents of the original official tarball are not modified.

==== Build Utilities ====

Multiple validated platforms have also been cross-compiled with build utilities supplied and residing outside of the official source distribution workarea, e.g. [http://opensslfoundation.com/fips/2.0/platforms/ios/setenv-ios-11.sh http://opensslfoundation.com/fips/2.0/platforms/ios/setenv-ios-11.sh] which contains:

# FIPS_SIG is the tool for determining the incore fingerprint
#export FIPS_SIG=/usr/local/ssl/fingerprint-macho
export FIPS_SIG="`pwd`"/iOS/incore_macho

The "incore" utilties (''incore, incore6x, msincore, incore_macho'') calculate and insert the [[incore digest]] of the executable file linked with the FIPS module, and are not used during creation of the actual FIPS module proper (''fipscanister.o'', ''fipscanister.lib''). Note most openssl-fips-2.0.N.tar.gz tarballs contain one or more incore utilities; these ''cannot be modified'' in place. However, specification of separate utility files residing ''outside'' of the unpacked tarball is permissible.

==== No-Nos ====

Some build environment modifications are known to be disallowed.

===== Code Path =====

The [[code path]] is an important concept. Modifications to the build environment that change the code path of the resulting binary code (e.g. adding/removing assembler optimizations, or changing between 32 and 64 bit code generation) mean that the original formally tested platform is no longer relevant.

==== Grey Areas ====

[TBD]

==== Conclusion ====

Some limited modifications to the build environment are permissible provided that:

* the contents of the official tarball are not modified, at all
* the canonical build commands are used (''gunzip ...; cd ...; ./config; make'')
* the code path is the same as for a formally tested platform

=== Application Linking ===

Ok, if you created the FIPS module (the fipscanister.lib and technically also the fipscanister.lib.sha1, fips_premain.c, fips_premain.c.sha1 files) *exactly* as documented in the Security Policy and without *any* modification of the ./openssl-fips-2.0.3/ workarea, *then* you have a FIPS module you can claim as FIPS 140-2 validated.

Having achieved that the next step is to link that FIPS module into an executable application. Here the restrictions are far less severe; consisting essentially of two responsibilities:

1) Verify the digests of the FIPS module (fipscanister.o, fips_premain.c) against the *.sha1 files.

2) Set the integrity test digest. The fipsld utility does than for native compiled, and an "incore" utility for cross-compilation. Different "incore" utilities are used for various cross-compiled platforms.

Note the CMVP does not (to our knowledge) impose any specific requirement on the "fipsld" or "incore" utilities. While it can be very dangerous to presume an understanding of their thought processes, as they see FIPS 140-2 validation from a very different perspective than the typical software developer/engineer, I believe it goes something like this:

The integrity digest is verified at runtime as part of the mandated POST (Power Up Self Test, a key FIPS 140-2 concept). The code that performs that check is carefully and formally reviewed and tested. That integrity test consists of calculating a HMAC-SHA1 digest of the TXT and RODATA segments of the FIPS module as mapped in live memory, and comparing it against a known value embedded in the module. The "fipsld" or "incore" utility stores that known value. No formal testing is required for that utility because for given any fixed string of bits (i.e. the TXT+RODATA segments) there is only one possible correct value for the HMAC-SHA1 digest. If an untested and defective fipsld/incore utility stores an incorrect value then the POST will fail, therefore only the latter need be formally tested.

FIPS Build Guidelines

2013-05-29T17:53:32Z

Stevem: Added Application Linking section

=== FIPS Module Build ===

The FIPS module is the binary file fipscanister.o (fipscanister.lib for Windows)
<ref>Technically speaking the FIPS module alsi includes the companion fipscanister.o.sha1,fips_premain.c, and fips_premain.c.sha1 files.
</ref>
created by the build process.

The [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf Security Policy] document defines a very specific procedure for creating a binary FIPS module from the official source distributions:

gunzip -c openssl-fips-2.0.''N''.tar.gz | tar xf -
cd openssl-fips-2.0.''N''
./config
make

(for Unix/Linux). The Security Policy and [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 NIST CMVP web site entry] also clearly state that the source distribution (tarball) ''cannot'' be modified, ''at all''. The unofficial [http://www.openssl.org/docs/fips/UserGuide-2.0.pdf FIPS user Guide] also notes this reestriction.

That is worth repeating as the question appears repeatedly: you '''cannot modify the contents of the official tarball'''. The CMVP has imposed that very specific prohibition on all of the OpenSSL FIPS Object Module validations. From the software developer/engineer perspective that prohibition is senseless and furstrating, but it is what it is. You can't modify the tarball, even if the tinest tweak would make the difference between success and failure in building the module for your platform of interest. The natural tendency of a software developer is to identify and implement the simplest and most elegant modification to fix a build or execution. That approach generally won't work when the goal is to claim FIPS 140-2 validated status for the resulting module.

----
Question: Okay, got it. The official canonical build commands given above must be used with an unmodified official tarball. The end result doesn't build a usable module for my platform if interest. Is there ''anything'' I ''can'' do?
----

Answer: Maybe.

The CMVP has provided specific guidance on some things that ''must'' be done (e.g. the canonical build commands) and some things that ''cannot'' be done (modification of the tarball contents). However, based on an extensive series of validations of specific platforms (Operational Environments in FIPS-speak) we can discern some general rules for a limited set of techniques that are presumptively permissible.

==== Environment scripts ====

The ./config command determines a build target from various inputs, for example the ''uname'' command for Unix/Linux systems for native compilation. For cross-compilation the target characteristics are determined from environment variables MACHINE, SYSTEM, RELEASE, etc. The use of a shell script that sets the appropriate environment variables is well established. For instance [http://opensslfoundation.com/fips/2.0/platforms/android/setenv-android-4.1.sh http://opensslfoundation.com/fips/2.0/platforms/android/setenv-android-4.1.sh]:

#!/bin/sh
# Cross-compile environment for Android on ARMv7
#
# This script assumes the Android NDK and the OpenSSL FIPS
# tarballs have been unpacked in the same directory

#android-sdk-linux/platforms Edit this to wherever you unpacked the NDK

if [ -d android-ndk-r8b ]; then
export ANDROID_NDK=$PWD/android-ndk-r8b
fi
if [ -d android-ndk-r8c ]; then
export ANDROID_NDK=$PWD/android-ndk-r8c
fi

# Edit to reference the incore script (usually in ./util/)
export FIPS_SIG=$PWD/openssl-fips-2.0.2/util/incore

for i in linux darwin
do
if [ -d $ANDROID_NDK/toolchains/arm-linux-androideabi-4.6/prebuilt/$i-x86/bin ]; then
PATH=$ANDROID_NDK/toolchains/arm-linux-androideabi-4.6/prebuilt/$i-x86/bin:$PATH
fi
done

export PATH

#
# Shouldn't need to edit anything past here.
#

export MACHINE=armv7l
export RELEASE=2.6.37
export SYSTEM=android
export ARCH=arm
export CROSS_COMPILE="arm-linux-androideabi-"
export ANDROID_DEV="$ANDROID_NDK/platforms/android-14/arch-arm/usr"
export HOSTCC=gcc

So in general specification of information needed to define the cross-compilation target for the toolkit is premissible, provided that the contents of the original official tarball are not modified.

==== Build Utilities ====

Multiple validated platforms have also been cross-compiled with build utilities supplied and residing outside of the official source distribution workarea, e.g. [http://opensslfoundation.com/fips/2.0/platforms/ios/setenv-ios-11.sh http://opensslfoundation.com/fips/2.0/platforms/ios/setenv-ios-11.sh] which contains:

# FIPS_SIG is the tool for determining the incore fingerprint
#export FIPS_SIG=/usr/local/ssl/fingerprint-macho
export FIPS_SIG="`pwd`"/iOS/incore_macho

The "incore" utilties (''incore, incore6x, msincore, incore_macho'') calculate and insert the [[incore digest]] of the executable file linked with the FIPS module, and are not used during creation of the actual FIPS module proper (''fipscanister.o'', ''fipscanister.lib''). Note most openssl-fips-2.0.N.tar.gz tarballs contain one or more incore utilities; these ''cannot be modified'' in place. However, specification of separate utility files residing ''outside'' of the unpacked tarball is permissible.

==== No-Nos ====

Some build environment modifications are known to be disallowed.

===== Code Path =====

The [[code path]] is an important concept. Modifications to the build environment that change the code path of the resulting binary code (e.g. adding/removing assembler optimizations, or changing between 32 and 64 bit code generation) mean that the original formally tested platform is no longer relevant.

==== Grey Areas ====

[TBD]

==== Conclusion ====

Some limited modifications to the build environment are permissible provided that:

* the contents of the official tarball are not modified, at all
* the canonical build commands are used (''gunzip ...; cd ...; ./config; make'')
* the code path is the same as for a formally tested platform

=== Application Linking ===

Ok, if you created the FIPS module (the fipscanister.lib and technically also the fipscanister.lib.sha1, fips_premain.c, fips_premain.c.sha1 files) *exactly* as documented in the Security Policy and without *any* modification of the ./openssl-fips-2.0.3/ workarea, *then* you have a FIPS module you can claim as FIPS 140-2 validated.

Having achieved that the next step is to link that FIPS module into an executable application. Here the restrictions are far less severe; consisting essentially of two responsibilities:

1) Verify the digests of the FIPS module (fipscanister.o, fips_premain.c) against the *.sha1 files.

2) Set the integrity test digest. The msincore utility does that in your situation. Different "incore" utilities are used for other cross-compiled platforms.

Note the CMVP does not (to our knowledge) impose any specific requirement on the "incore" utility. While it can be very dangerous to presume an understanding of their thought processes, as they see FIPS 140-2 validation from a very different perspective than the typical software developer/engineer, I believe it goes something like this:

The integrity digest is verified at runtime as part of the mandated POST (Power Up Self Test, a key FIPS 140-2 concept). The code that performs that check is carefully and formally reviewed and tested. That integrity test consists of calculating a HMAC-SHA1 digest of the TXT and RODATA segments of the FIPS module as mapped in live memory, and comparing it against a known value embedded in the module. The "incore" utility (in this case) stores that known value. No formal testing is required for that utility because for given any fixed string of bits (i.e. the TXT+RODATA segments) there is only one possible correct value for the HMAC-SHA1 digest. If an untested and defective incore utility stores an incorrect value then the POST will fail, therefore only the latter need be formally tested.

FIPS Build Guidelines

2013-05-29T17:03:26Z

Stevem: New levels -- "Cite" extension needed (mediawiki-extensions-base)

FIPS Build Guidelines

2013-05-29T14:45:39Z

Stevem: Added code path and summary sections

The [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf Security Policy] document defines a very specific procedure for creating a binary module from the official source distributions:

gunzip -c openssl-fips-2.0.''N''.tar.gz | tar xf -
cd openssl-fips-2.0.''N''
./config
make

(for Unix/Linux). The Security Policy and [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 NIST CMVP web site entry] also clearly state that the source distribution (tarball) ''cannot'' be modified, ''at all''. The unofficial [http://www.openssl.org/docs/fips/UserGuide-2.0.pdf FIPS user Guide] also notes this reestriction.

That is worth repeating as the question appears repeatedly: you '''cannot modify the contents of the official tarball'''. The CMVP has imposed that very specific prohibition on all of the OpenSSL FIPS Object Module validations. From the software developer/engineer perspective that prohibition is senseless and furstrating, but it is what it is. You can't modify the tarball, even if the tinest tweak would make the difference between success and failure in building the module for your platform of interest. The natural tendency of a software developer is to identify and implement the simplest and most elegant modification to fix a build or execution. That approach generally won't work when the goal is to claim FIPS 140-2 validated status for the resulting module.

----
Question: Okay, got it. The official canonical build commands given above must be used with an unmodified official tarball. The end result doesn't build a usable module for my platform if interest. Is there ''anything'' I ''can'' do?
----

Answer: Maybe.

The CMVP has provided specific guidance on some things that ''must'' be done (e.g. the canonical build commands) and some things that ''cannot'' be done (modification of the tarball contents). However, based on an extensive series of validations of specific platforms (Operational Environments in FIPS-speak) we can discern some general rules for a limited set of techniques that are presumptively permissible.

==== Environment scripts ====

The ./config command determines a build target from various inputs, for example the ''uname'' command for Unix/Linux systems for native compilation. For cross-compilation the target characteristics are determined from environment variables MACHINE, SYSTEM, RELEASE, etc. The use of a shell script that sets the appropriate environment variables is well established. For instance [http://opensslfoundation.com/fips/2.0/platforms/android/setenv-android-4.1.sh http://opensslfoundation.com/fips/2.0/platforms/android/setenv-android-4.1.sh]:

#!/bin/sh
# Cross-compile environment for Android on ARMv7
#
# This script assumes the Android NDK and the OpenSSL FIPS
# tarballs have been unpacked in the same directory

#android-sdk-linux/platforms Edit this to wherever you unpacked the NDK

if [ -d android-ndk-r8b ]; then
export ANDROID_NDK=$PWD/android-ndk-r8b
fi
if [ -d android-ndk-r8c ]; then
export ANDROID_NDK=$PWD/android-ndk-r8c
fi

# Edit to reference the incore script (usually in ./util/)
export FIPS_SIG=$PWD/openssl-fips-2.0.2/util/incore

for i in linux darwin
do
if [ -d $ANDROID_NDK/toolchains/arm-linux-androideabi-4.6/prebuilt/$i-x86/bin ]; then
PATH=$ANDROID_NDK/toolchains/arm-linux-androideabi-4.6/prebuilt/$i-x86/bin:$PATH
fi
done

export PATH

#
# Shouldn't need to edit anything past here.
#

export MACHINE=armv7l
export RELEASE=2.6.37
export SYSTEM=android
export ARCH=arm
export CROSS_COMPILE="arm-linux-androideabi-"
export ANDROID_DEV="$ANDROID_NDK/platforms/android-14/arch-arm/usr"
export HOSTCC=gcc

So in general specification of information needed to define the cross-compilation target for the toolkit is premissible, provided that the contents of the original official tarball are not modified.

==== Build Utilities ====

Multiple validated platforms have also been cross-compiled with build utilities supplied and residing outside of the official source distribution workarea, e.g. [http://opensslfoundation.com/fips/2.0/platforms/ios/setenv-ios-11.sh http://opensslfoundation.com/fips/2.0/platforms/ios/setenv-ios-11.sh] which contains:

# FIPS_SIG is the tool for determining the incore fingerprint
#export FIPS_SIG=/usr/local/ssl/fingerprint-macho
export FIPS_SIG="`pwd`"/iOS/incore_macho

The "incore" utilties (''incore, incore6x, msincore, incore_macho'') calculate and insert the [[incore digest]] of the executable file linked with the FIPS module, and are not used during creation of the actual FIPS module proper (''fipscanister.o'', ''fipscanister.lib''). Note most openssl-fips-2.0.N.tar.gz tarballs contain one or more incore utilities; these ''cannot be modified'' in place. However, specification of separate utility files residing ''outside'' of the unpacked tarball is permissible.

==== Code Path ====

The [[code path]] is an important concept. Modifications to the build environment that change the code path of the resulting binary code (e.g. adding/removing assembler optimizations, or changing between 32 and 64 bit code generation) mean that the original formally tested platform is no longer relevant.

==== Conclusion ====

Some limited modifications to the build environment are permissible provided that:

* the contents of the official tarball are not modified, at all
* the canonical build commands are used (''gunzip ...; cd ...; ./config; make'')
* the code path is the same as for a formally tested platform

FIPS Build Guidelines

2013-05-29T14:38:23Z

Stevem: Initial draft of new page

FIPS mode()

2013-05-29T13:23:47Z

Stevem: Remove font effect artifects

----
'''NAME'''

FIPS_mode - retrieve the current FIPS 140-2 mode of operation

----
'''SYNOPSIS'''

#include <openssl/crypto.h>

int FIPS_mode(void);

----
'''DESCRIPTION'''

FIPS_mode() is used to determine the FIPS mode of operation by a program utilizing the services of the validated library. The library must have been built with the FIPS Object Module, and the FIPS Object Module must have been acquired, built, and installed in accordance with the Security Policy.

The return value is either 0 to indicate that the FIPS mode of operation is not enabled, or the value used for the ONOFF parameter passed to an earlier successful call to FIPS_mode_set(). Effectively any non-zero value indicates FIPS mode; values other than 1 may have additional significance such as designating an additional restriction to Suite B algorithms.

If the library was built without support of the FIPS Object Module, then the function will return 0 with an error code of CRYPTO_R_FIPS_MODE_NOT_SUPPORTED (0x0f06d065).

----
'''RETURN VALUES'''

A return code of non-zero indicates FIPS mode, 0 indicates non-FIPS mode. When called from a version of OpenSSL that is not "FIPS capable" (capable of utilizing an embedded FIPS Object Module), then FIPS_mode() will always return 0.

----
'''SEE ALSO'''

FIPS_mode_set(3), FIPS_selftest(3)

----
'''NOTES'''

FIPS_mode() was formerly included with <openssl/fips.h>.

----
'''HISTORY'''

FIPS support was introduced in version 0.9.7 of OpenSSL.

[[Category:FIPS 140-2]]
[[Category:Crypto API]]
[[Category:C level]]

Command Line Utilities

2013-05-28T20:47:02Z

Stevem: /* rsa / genrsa */

[http://www.openssl.org/docs/apps/openssl.html OpenSSL site command line tools]

== Commands by purpose ==

Following commands are grouped by purpose using a different grouping than of default openssl documentation / help.

=== Get information about your openssl toolkit ===

When installed on your system openssl binary is entry point for many functions.

* launching openssl without any parameter will enter an interactive mode with an OpenSSL> prompt
** to quit: quit
** enter a command it will set a command context in which parameters depends on command.

==== version ====

OpenSSL> version
OpenSSL 1.0.1e 11 Feb 2013

==== ciphers ====

returns SSL/TLS ciphers supported.

<pre>
OpenSSL> ciphers
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5
</pre>

openssl list-cipher-algorithms

openssl list-public-key-algorithms
<pre>
Name: OpenSSL RSA method
Type: Builtin Algorithm
OID: rsaEncryption
PEM string: RSA
Name: rsa
Type: Alias to rsaEncryption
Name: OpenSSL PKCS#3 DH method
Type: Builtin Algorithm
OID: dhKeyAgreement
PEM string: DH
Name: dsaWithSHA
Type: Alias to dsaEncryption
Name: dsaEncryption-old
Type: Alias to dsaEncryption
Name: dsaWithSHA1-old
Type: Alias to dsaEncryption
Name: dsaWithSHA1
Type: Alias to dsaEncryption
Name: OpenSSL DSA method
Type: Builtin Algorithm
OID: dsaEncryption
PEM string: DSA
Name: OpenSSL EC algorithm
Type: Builtin Algorithm
OID: id-ecPublicKey
PEM string: EC
Name: OpenSSL HMAC method
Type: Builtin Algorithm
OID: hmac
PEM string: HMAC
Name: OpenSSL CMAC method
Type: Builtin Algorithm
OID: cmac
PEM string: CMAC
</pre>

==== engine ====

OpenSSL> engine
(rsax) RSAX engine support
(dynamic) Dynamic engine loading support

==== speed ====

returns informations of toolkit performance on cryptographic functions computations.

( Ex: on Linux 3.1.0-1-amd64 #1 SMP x86_64 GNU/Linux, HP dv7 i7 4Gb )

<pre>
Doing md4 for 3s on 16 size blocks: 12430613 md4's in 3.00s
...
Doing md5 for 3s on 16 size blocks: 8943943 md5's in 2.99s
Doing md5 for 3s on 64 size blocks: 6560162 md5's in 3.00s
Doing md5 for 3s on 256 size blocks: 3674563 md5's in 3.00s
Doing md5 for 3s on 1024 size blocks: 1325803 md5's in 3.00s
Doing md5 for 3s on 8192 size blocks: 190271 md5's in 3.00s
Doing hmac(md5) for 3s on 16 size blocks: 7289025 hmac(md5)'s in 3.00s
Doing hmac(md5) for 3s on 64 size blocks: 5519732 hmac(md5)'s in 3.00s
Doing hmac(md5) for 3s on 256 size blocks: 3319123 hmac(md5)'s in 3.00s
Doing hmac(md5) for 3s on 1024 size blocks: 1275475 hmac(md5)'s in 3.00s
Doing hmac(md5) for 3s on 8192 size blocks: 187134 hmac(md5)'s in 3.00s
Doing sha1 for 3s on 16 size blocks: 10089842 sha1's in 2.99s
Doing sha1 for 3s on 64 size blocks: 7033355 sha1's in 3.00s
Doing sha1 for 3s on 256 size blocks: 3919372 sha1's in 3.00s
Doing sha1 for 3s on 1024 size blocks: 1374314 sha1's in 3.00s
Doing sha1 for 3s on 8192 size blocks: 198808 sha1's in 3.00s
Doing sha256 for 3s on 16 size blocks: 6462822 sha256's in 3.00s
Doing sha256 for 3s on 64 size blocks: 3504641 sha256's in 3.00s
Doing sha256 for 3s on 256 size blocks: 1486771 sha256's in 3.00s
Doing sha256 for 3s on 1024 size blocks: 440613 sha256's in 3.00s
Doing sha256 for 3s on 8192 size blocks: 58418 sha256's in 3.00s
Doing sha512 for 3s on 16 size blocks: 5040453 sha512's in 2.99s
Doing sha512 for 3s on 64 size blocks: 5089425 sha512's in 3.00s
Doing sha512 for 3s on 256 size blocks: 1865240 sha512's in 3.00s
Doing sha512 for 3s on 1024 size blocks: 643708 sha512's in 3.00s
Doing sha512 for 3s on 8192 size blocks: 90615 sha512's in 3.00s
...
Doing whirlpool for 3s on 8192 size blocks: 33204 whirlpool's in 3.00s
...
Doing rmd160 for 3s on 8192 size blocks: 66719 rmd160's in 3.00s
...
Doing rc4 for 3s on 8192 size blocks: 238972 rc4's in 3.00s
...
Doing des cbc for 3s on 8192 size blocks: 19837 des cbc's in 3.00s
...
Doing des ede3 for 3s on 8192 size blocks: 7706 des ede3's in 3.00s
...
Doing aes-128 cbc for 3s on 8192 size blocks: 35217 aes-128 cbc's in 3.00s
...
Doing aes-192 cbc for 3s on 8192 size blocks: 29225 aes-192 cbc's in 3.01s
...
Doing aes-256 cbc for 3s on 8192 size blocks: 24414 aes-256 cbc's in 3.00s
...
Doing aes-256 ige for 3s on 8192 size blocks: 23331 aes-256 ige's in 2.99s
...
</pre>

=== Basic encryption ===

==== Basic file ====

to cipher a file or data to protect and share it protected by a shared key.

symetric cipher :
[[AES]] [[Blowfish]] [[RC4]] [[3DES]] [[RC2]] [[DES]] [[CAST5]] [[SEED]]

block to stream conversion :
[[ECB]] [[CBC]] [[OFB]] [[CFB]] [[CTR]] [[XTS]] [[GCM]]

compression :
[[ZLIB]]

<pre>
Cipher commands (see the `enc' command for more details)
aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb
aes-256-cbc aes-256-ecb base64 bf
bf-cbc bf-cfb bf-ecb bf-ofb
camellia-128-cbc camellia-128-ecb camellia-192-cbc camellia-192-ecb
camellia-256-cbc camellia-256-ecb cast cast-cbc
cast5-cbc cast5-cfb cast5-ecb cast5-ofb
des des-cbc des-cfb des-ecb
des-ede des-ede-cbc des-ede-cfb des-ede-ofb
des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb
des-ofb des3 desx rc2
rc2-40-cbc rc2-64-cbc rc2-cbc rc2-cfb
rc2-ecb rc2-ofb rc4 rc4-40
seed seed-cbc seed-cfb seed-ecb
seed-ofb zlib
</pre>

<pre>
openssl enc --help
unknown option '--help'
options are
-in <file> input file
-out <file> output file
-pass <arg> pass phrase source
-e encrypt
-d decrypt
-a/-base64 base64 encode/decode, depending on encryption flag
-k passphrase is the next argument
-kfile passphrase is the first line of the file argument
-md the next argument is the md to use to create a key
from a passphrase. One of md2, md5, sha or sha1
-S salt in hex is the next argument
-K/-iv key/iv in hex is the next argument
-[pP] print the iv/key (then exit if -P)
-bufsize <n> buffer size
-nopad disable standard block padding
-engine e use engine e, possibly a hardware device.
Cipher Types
-aes-128-cbc -aes-128-cfb -aes-128-cfb1
-aes-128-cfb8 -aes-128-ctr -aes-128-ecb
-aes-128-gcm -aes-128-ofb -aes-128-xts
-aes-192-cbc -aes-192-cfb -aes-192-cfb1
-aes-192-cfb8 -aes-192-ctr -aes-192-ecb
-aes-192-gcm -aes-192-ofb -aes-256-cbc
-aes-256-cfb -aes-256-cfb1 -aes-256-cfb8
-aes-256-ctr -aes-256-ecb -aes-256-gcm
-aes-256-ofb -aes-256-xts -aes128
-aes192 -aes256 -bf
-bf-cbc -bf-cfb -bf-ecb
-bf-ofb -blowfish -camellia-128-cbc
-camellia-128-cfb -camellia-128-cfb1 -camellia-128-cfb8
-camellia-128-ecb -camellia-128-ofb -camellia-192-cbc
-camellia-192-cfb -camellia-192-cfb1 -camellia-192-cfb8
-camellia-192-ecb -camellia-192-ofb -camellia-256-cbc
-camellia-256-cfb -camellia-256-cfb1 -camellia-256-cfb8
-camellia-256-ecb -camellia-256-ofb -camellia128
-camellia192 -camellia256 -cast
-cast-cbc -cast5-cbc -cast5-cfb
-cast5-ecb -cast5-ofb -des
-des-cbc -des-cfb -des-cfb1
-des-cfb8 -des-ecb -des-ede
-des-ede-cbc -des-ede-cfb -des-ede-ofb
-des-ede3 -des-ede3-cbc -des-ede3-cfb
-des-ede3-cfb1 -des-ede3-cfb8 -des-ede3-ofb
-des-ofb -des3 -desx
-desx-cbc -id-aes128-GCM -id-aes192-GCM
-id-aes256-GCM -rc2 -rc2-40-cbc
-rc2-64-cbc -rc2-cbc -rc2-cfb
-rc2-ecb -rc2-ofb -rc4
-rc4-40 -rc4-hmac-md5 -seed
-seed-cbc -seed-cfb -seed-ecb
-seed-ofb
</pre>

==== Mail / SMIME ====

===== smime v2 pkcs7 1.5 =====

<pre>
openssl smime --help
Usage smime [options] cert.pem ...
where options are
-encrypt encrypt message
-decrypt decrypt encrypted message
-sign sign message
-verify verify signed message
-pk7out output PKCS#7 structure
-des3 encrypt with triple DES
-des encrypt with DES
-seed encrypt with SEED
-rc2-40 encrypt with RC2-40 (default)
-rc2-64 encrypt with RC2-64
-rc2-128 encrypt with RC2-128
-aes128, -aes192, -aes256
encrypt PEM output with cbc aes
-camellia128, -camellia192, -camellia256
encrypt PEM output with cbc camellia
-nointern don't search certificates in message for signer
-nosigs don't verify message signature
-noverify don't verify signers certificate
-nocerts don't include signers certificate when signing
-nodetach use opaque signing
-noattr don't include any signed attributes
-binary don't translate message to text
-certfile file other certificates file
-signer file signer certificate file
-recip file recipient certificate file for decryption
-in file input file
-inform arg input format SMIME (default), PEM or DER
-inkey file input private key (if not signer or recipient)
-keyform arg input private key format (PEM or ENGINE)
-out file output file
-outform arg output format SMIME (default), PEM or DER
-content file supply or override content for detached signature
-to addr to address
-from ad from address
-subject s subject
-text include or delete text MIME headers
-CApath dir trusted certificates directory
-CAfile file trusted certificates file
-crl_check check revocation status of signer's certificate using CRLs
-crl_check_all check revocation status of signer's certificate chain using CRLs
-engine e use engine e, possibly a hardware device.
-passin arg input file pass phrase source
-rand file:file:...
load the file (or the files in the directory) into
the random number generator
cert.pem recipient certificate(s) for encryption
</pre>

===== smime v3 cms =====

<pre>
openssl cms --help
Usage cms [options] cert.pem ...
where options are
-encrypt encrypt message
-decrypt decrypt encrypted message
-sign sign message
-verify verify signed message
-cmsout output CMS structure
-des3 encrypt with triple DES
-des encrypt with DES
-seed encrypt with SEED
-rc2-40 encrypt with RC2-40 (default)
-rc2-64 encrypt with RC2-64
-rc2-128 encrypt with RC2-128
-aes128, -aes192, -aes256
encrypt PEM output with cbc aes
-camellia128, -camellia192, -camellia256
encrypt PEM output with cbc camellia
-nointern don't search certificates in message for signer
-nosigs don't verify message signature
-noverify don't verify signers certificate
-nocerts don't include signers certificate when signing
-nodetach use opaque signing
-noattr don't include any signed attributes
-binary don't translate message to text
-certfile file other certificates file
-certsout file certificate output file
-signer file signer certificate file
-recip file recipient certificate file for decryption
-keyid use subject key identifier
-in file input file
-inform arg input format SMIME (default), PEM or DER
-inkey file input private key (if not signer or recipient)
-keyform arg input private key format (PEM or ENGINE)
-out file output file
-outform arg output format SMIME (default), PEM or DER
-content file supply or override content for detached signature
-to addr to address
-from ad from address
-subject s subject
-text include or delete text MIME headers
-CApath dir trusted certificates directory
-CAfile file trusted certificates file
-crl_check check revocation status of signer's certificate using CRLs
-crl_check_all check revocation status of signer's certificate chain using CRLs
-engine e use engine e, possibly a hardware device.
-passin arg input file pass phrase source
-rand file:file:...
load the file (or the files in the directory) into
the random number generator
cert.pem recipient certificate(s) for encryption
</pre>

=== Create / Handle Public Key Certificates ===

This requires you have a knowledge of what PKI is ( Certificate Authorities, Certificate Request, Certificate, Public Key, Private Key )

Classical use case is to obtain a valid Certificate for a Secured Web site ( https protocol ).
First you create a Private Key ( will be created together with Public key ).
Then create a Certificate Request for that private key with some informations for purpose of future Certificate.
Then send that Certificate Request to a Certificate Authority ( CA ) that will issue a Certificate that CA signed. For well known CA you need to pay.
Up to you to install your Private key together with the received Certificate on your system.

It exists graphical front-end to operate openssl wihtin a GUI : [http://xca.sourceforge.net/ XCA]

==== Key Generation ====

===== rsa / genrsa =====

RSA is the most common type of Public/Private Key.
Private Key part should never be disclosed while public key part is ... public.

<pre>
openssl genrsa --help
usage: genrsa [args] [numbits]
-des encrypt the generated key with DES in cbc mode
-des3 encrypt the generated key with DES in ede cbc mode (168 bit key)
-seed
encrypt PEM output with cbc seed
-aes128, -aes192, -aes256
encrypt PEM output with cbc aes
-camellia128, -camellia192, -camellia256
encrypt PEM output with cbc camellia
-out file output the key to 'file
-passout arg output file pass phrase source
-f4 use F4 (0x10001) for the E value
-3 use 3 for the E value
-engine e use engine e, possibly a hardware device.
-rand file:file:...
load the file (or the files in the directory) into
the random number generator
</pre>

<pre>
rsa help
unknown option help
rsa [options] <infile >outfile
where options are
-inform arg input format - one of DER NET PEM
-outform arg output format - one of DER NET PEM
-in arg input file
-sgckey Use IIS SGC key format
-passin arg input file pass phrase source
-out arg output file
-passout arg output file pass phrase source
-des encrypt PEM output with cbc des
-des3 encrypt PEM output with ede cbc des using 168 bit key
-seed encrypt PEM output with cbc seed
-aes128, -aes192, -aes256
encrypt PEM output with cbc aes
-camellia128, -camellia192, -camellia256
encrypt PEM output with cbc camellia
-text print the key in text
-noout don't print key out
-modulus print the RSA key modulus
-check verify key consistency
-pubin expect a public key in input file
-pubout output a public key
-engine e use engine e, possibly a hardware device.
error in rsa
</pre>

===== dsa / gendsa=====

dsa is a less common Public/Private key scheme, but can be seen anyway, so ...

<pre>
openssl gendsa
usage: gendsa [args] dsaparam-file
-out file - output the key to 'file'
-des - encrypt the generated key with DES in cbc mode
-des3 - encrypt the generated key with DES in ede cbc mode (168 bit key)
-seed
encrypt PEM output with cbc seed
-aes128, -aes192, -aes256
encrypt PEM output with cbc aes
-camellia128, -camellia192, -camellia256
encrypt PEM output with cbc camellia
-engine e - use engine e, possibly a hardware device.
-rand file:file:...
- load the file (or the files in the directory) into
the random number generator
dsaparam-file
- a DSA parameter file as generated by the dsaparam command

</pre>

<pre>
OpenSSL> dsa help
unknown option help
dsa [options] <infile >outfile
where options are
-inform arg input format - DER or PEM
-outform arg output format - DER or PEM
-in arg input file
-passin arg input file pass phrase source
-out arg output file
-passout arg output file pass phrase source
-engine e use engine e, possibly a hardware device.
-des encrypt PEM output with cbc des
-des3 encrypt PEM output with ede cbc des using 168 bit key
-aes128, -aes192, -aes256
encrypt PEM output with cbc aes
-camellia128, -camellia192, -camellia256
encrypt PEM output with cbc camellia
-seed encrypt PEM output with cbc seed
-text print the key in text
-noout don't print key out
-modulus print the DSA public value
error in dsa
</pre>

===== Elliptic Curves / ec ecparam =====

[[Elliptic_Curve_Cryptography]]

<pre>
openssl ecparam --help
unknown option --help
ecparam [options] <infile >outfile
where options are
-inform arg input format - default PEM (DER or PEM)
-outform arg output format - default PEM
-in arg input file - default stdin
-out arg output file - default stdout
-noout do not print the ec parameter
-text print the ec parameters in text form
-check validate the ec parameters
-C print a 'C' function creating the parameters
-name arg use the ec parameters with 'short name' name
-list_curves prints a list of all currently available curve 'short names'
-conv_form arg specifies the point conversion form
possible values: compressed
uncompressed (default)
hybrid
-param_enc arg specifies the way the ec parameters are encoded
in the asn1 der encoding
possible values: named_curve (default)
explicit
-no_seed if 'explicit' parameters are chosen do not use the seed
-genkey generate ec key
-rand file files to use for random number input
-engine e use engine e, possibly a hardware device
</pre>

<pre>
ec [options] <infile >outfile
where options are
-inform arg input format - DER or PEM
-outform arg output format - DER or PEM
-in arg input file
-passin arg input file pass phrase source
-out arg output file
-passout arg output file pass phrase source
-engine e use engine e, possibly a hardware device.
-des encrypt PEM output, instead of 'des' every other
cipher supported by OpenSSL can be used
-text print the key
-noout don't print key out
-param_out print the elliptic curve parameters
-conv_form arg specifies the point conversion form
possible values: compressed
uncompressed (default)
hybrid
-param_enc arg specifies the way the ec parameters are encoded
in the asn1 der encoding
possible values: named_curve (default)
explicit
</pre>

==== Certificate Authority / ca ====

When you want to act as a Certificate Authority.

OpenSSL> ca
Using configuration from /usr/lib/ssl/openssl.cnf
Error opening CA private key ./demoCA/private/cakey.pem
140492277311144:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('./demoCA/private/cakey.pem','r')
140492277311144:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:
unable to load CA private key
error in ca

By default you don't have ca created...

==== Certificate Request / pkcs10 / req ====

OpenSSL> req ?
unknown option ?
req [options] <infile >outfile
where options are
-inform arg input format - DER or PEM
-outform arg output format - DER or PEM
-in arg input file
-out arg output file
-text text form of request
-pubkey output public key
-noout do not output REQ
-verify verify signature on REQ
-modulus RSA modulus
-nodes don't encrypt the output key
-engine e use engine e, possibly a hardware device
-subject output the request's subject
-passin private key password source
-key file use the private key contained in file
-keyform arg key file format
-keyout arg file to send the key to
-rand file:file:...
load the file (or the files in the directory) into
the random number generator
-newkey rsa:bits generate a new RSA key of 'bits' in size
-newkey dsa:file generate a new DSA key, parameters taken from CA in 'file'
-newkey ec:file generate a new EC key, parameters taken from CA in 'file'
-[digest] Digest to sign with (md5, sha1, md2, mdc2, md4)
-config file request template file.
-subj arg set or modify request subject
-multivalue-rdn enable support for multivalued RDNs
-new new request.
-batch do not ask anything during request generation
-x509 output a x509 structure instead of a cert. req.
-days number of days a certificate generated by -x509 is valid for.
-set_serial serial number to use for a certificate generated by -x509.
-newhdr output "NEW" in the header lines
-asn1-kludge Output the 'request' in a format that is wrong but some CA's
have been reported as requiring
-extensions .. specify certificate extension section (override value in config file)
-reqexts .. specify request extension section (override value in config file)
-utf8 input characters are UTF8 (default ASCII)
-nameopt arg - various certificate name options
-reqopt arg - various request text options

error in req

==== Certificates AKA x509 ====

x509 command allows you to display content of a x509 certificate and to convert it from/to [[PEM]], [[NET]] or [[DER]] formats.

OpenSSL> x509 help
unknown option help
usage: x509 args
-inform arg - input format - default PEM (one of DER, NET or PEM)
-outform arg - output format - default PEM (one of DER, NET or PEM)
-keyform arg - private key format - default PEM
-CAform arg - CA format - default PEM
-CAkeyform arg - CA key format - default PEM
-in arg - input file - default stdin
-out arg - output file - default stdout
-passin arg - private key password source
-serial - print serial number value
-subject_hash - print subject hash value
-subject_hash_old - print old-style (MD5) subject hash value
-issuer_hash - print issuer hash value
-issuer_hash_old - print old-style (MD5) issuer hash value
-hash - synonym for -subject_hash
-subject - print subject DN
-issuer - print issuer DN
-email - print email address(es)
-startdate - notBefore field
-enddate - notAfter field
-purpose - print out certificate purposes
-dates - both Before and After dates
-modulus - print the RSA key modulus
-pubkey - output the public key
-fingerprint - print the certificate fingerprint
-alias - output certificate alias
-noout - no certificate output
-ocspid - print OCSP hash values for the subject name and public key
-ocsp_uri - print OCSP Responder URL(s)
-trustout - output a "trusted" certificate
-clrtrust - clear all trusted purposes
-clrreject - clear all rejected purposes
-addtrust arg - trust certificate for a given purpose
-addreject arg - reject certificate for a given purpose
-setalias arg - set certificate alias
-days arg - How long till expiry of a signed certificate - def 30 days
-checkend arg - check whether the cert expires in the next arg seconds
exit 1 if so, 0 if not
-signkey arg - self sign cert with arg
-x509toreq - output a certification request object
-req - input is a certificate request, sign and output.
-CA arg - set the CA certificate, must be PEM format.
-CAkey arg - set the CA key, must be PEM format
missing, it is assumed to be in the CA file.
-CAcreateserial - create serial number file if it does not exist
-CAserial arg - serial file
-set_serial - serial number to use
-text - print the certificate in text form
-C - print out C code forms
-md2/-md5/-sha1/-mdc2 - digest to use
-extfile - configuration file with X509V3 extensions to add
-extensions - section from config file with X509V3 extensions to add
-clrext - delete extensions before signing and input certificate
-nameopt arg - various certificate name options
-engine e - use engine e, possibly a hardware device.
-certopt arg - various certificate text options

==== Client Certificates AKA pkcs12 ====

Client Certificate is a language abuse, but anyway it is kind of file you need to install on your system when SSL/TLS server require Client Authentication.
Those kind of certificates credentials are known with .'''pkcs12''' or .'''pfx''' file extension.
They contains a x509 Certificate and the public/private key of client. Those files are then very sensible to handle with same security as a private key.

<pre>
Usage: pkcs12 [options]
where options are
-export output PKCS12 file
-chain add certificate chain
-inkey file private key if not infile
-certfile f add all certs in f
-CApath arg - PEM format directory of CA's
-CAfile arg - PEM format file of CA's
-name "name" use name as friendly name
-caname "nm" use nm as CA friendly name (can be used more than once).
-in infile input filename
-out outfile output filename
-noout don't output anything, just verify.
-nomacver don't verify MAC.
-nocerts don't output certificates.
-clcerts only output client certificates.
-cacerts only output CA certificates.
-nokeys don't output private keys.
-info give info about PKCS#12 structure.
-des encrypt private keys with DES
-des3 encrypt private keys with triple DES (default)
-seed encrypt private keys with seed
-aes128, -aes192, -aes256
encrypt PEM output with cbc aes
-camellia128, -camellia192, -camellia256
encrypt PEM output with cbc camellia
-nodes don't encrypt private keys
-noiter don't use encryption iteration
-nomaciter don't use MAC iteration
-maciter use MAC iteration
-nomac don't generate MAC
-twopass separate MAC, encryption passwords
-descert encrypt PKCS#12 certificates with triple DES (default RC2-40)
-certpbe alg specify certificate PBE algorithm (default RC2-40)
-keypbe alg specify private key PBE algorithm (default 3DES)
-macalg alg digest algorithm used in MAC (default SHA1)
-keyex set MS key exchange type
-keysig set MS key signature type
-password p set import/export password source
-passin p input file pass phrase source
-passout p output file pass phrase source
-engine e use engine e, possibly a hardware device.
-rand file:file:...
load the file (or the files in the directory) into
the random number generator
-CSP name Microsoft CSP name
-LMK Add local machine keyset attribute to private key
</pre>

=== SSL/TLS and Certificates ONLINE services ===

==== s_server ====

This implements a generic SSL/TLS server.

<pre>
openssl s_server
Error opening server certificate private key file server.pem
139811478357672:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('server.pem','r')
139811478357672:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:
unable to load server certificate private key file
</pre>

'''you need to provide certificate and private key to be able to run SSL/TLS server.'''

<pre>
openssl s_server --help
unknown option --help
usage: s_server [args ...]

-accept arg - port to accept on (default is 4433)
-context arg - set session ID context
-verify arg - turn on peer certificate verification
-Verify arg - turn on peer certificate verification, must have a cert.
-cert arg - certificate file to use
(default is server.pem)
-crl_check - check the peer certificate has not been revoked by its CA.
The CRL(s) are appended to the certificate file
-crl_check_all - check the peer certificate has not been revoked by its CA
or any other CRL in the CA chain. CRL(s) are appened to the
the certificate file.
-certform arg - certificate format (PEM or DER) PEM default
-key arg - Private Key file to use, in cert file if
not specified (default is server.pem)
-keyform arg - key format (PEM, DER or ENGINE) PEM default
-pass arg - private key file pass phrase source
-dcert arg - second certificate file to use (usually for DSA)
-dcertform x - second certificate format (PEM or DER) PEM default
-dkey arg - second private key file to use (usually for DSA)
-dkeyform arg - second key format (PEM, DER or ENGINE) PEM default
-dpass arg - second private key file pass phrase source
-dhparam arg - DH parameter file to use, in cert file if not specified
or a default set of parameters is used
-named_curve arg - Elliptic curve name to use for ephemeral ECDH keys.
Use "openssl ecparam -list_curves" for all names
(default is nistp256).
-nbio - Run with non-blocking IO
-nbio_test - test with the non-blocking test bio
-crlf - convert LF from terminal into CRLF
-debug - Print more output
-msg - Show protocol messages
-state - Print the SSL states
-CApath arg - PEM format directory of CA's
-CAfile arg - PEM format file of CA's
-nocert - Don't use any certificates (Anon-DH)
-cipher arg - play with 'openssl ciphers' to see what goes here
-serverpref - Use server's cipher preferences
-quiet - No server output
-no_tmp_rsa - Do not generate a tmp RSA key
-psk_hint arg - PSK identity hint to use
-psk arg - PSK in hex (without 0x)
-srpvfile file - The verifier file for SRP
-srpuserseed string - A seed string for a default user salt.
-ssl2 - Just talk SSLv2
-ssl3 - Just talk SSLv3
-tls1_2 - Just talk TLSv1.2
-tls1_1 - Just talk TLSv1.1
-tls1 - Just talk TLSv1
-dtls1 - Just talk DTLSv1
-timeout - Enable timeouts
-mtu - Set link layer MTU
-chain - Read a certificate chain
-no_ssl2 - Just disable SSLv2
-no_ssl3 - Just disable SSLv3
-no_tls1 - Just disable TLSv1
-no_tls1_1 - Just disable TLSv1.1
-no_tls1_2 - Just disable TLSv1.2
-no_dhe - Disable ephemeral DH
-no_ecdhe - Disable ephemeral ECDH
-bugs - Turn on SSL bug compatibility
-www - Respond to a 'GET /' with a status page
-WWW - Respond to a 'GET /<path> HTTP/1.0' with file ./<path>
-HTTP - Respond to a 'GET /<path> HTTP/1.0' with file ./<path>
with the assumption it contains a complete HTTP response.
-engine id - Initialise and use the specified engine
-id_prefix arg - Generate SSL/TLS session IDs prefixed by 'arg'
-rand file:file:...
-servername host - servername for HostName TLS extension
-servername_fatal - on mismatch send fatal alert (default warning alert)
-cert2 arg - certificate file to use for servername
(default is server2.pem)
-key2 arg - Private Key file to use for servername, in cert file if
not specified (default is server2.pem)
-tlsextdebug - hex dump of all TLS extensions received
-no_ticket - disable use of RFC4507bis session tickets
-legacy_renegotiation - enable use of legacy renegotiation (dangerous)
-nextprotoneg arg - set the advertised protocols for the NPN extension (comma-separated list)
-use_srtp profiles - Offer SRTP key management with a colon-separated profile list
-keymatexport label - Export keying material using label
-keymatexportlen len - Export len bytes of keying material (default 20)
</pre>

==== s_client ====

This implements a generic SSL/TLS client

<pre>
unknown option --help
usage: s_client args

-host host - use -connect instead
-port port - use -connect instead
-connect host:port - who to connect to (default is localhost:4433)
-verify arg - turn on peer certificate verification
-cert arg - certificate file to use, PEM format assumed
-certform arg - certificate format (PEM or DER) PEM default
-key arg - Private key file to use, in cert file if
not specified but cert file is.
-keyform arg - key format (PEM or DER) PEM default
-pass arg - private key file pass phrase source
-CApath arg - PEM format directory of CA's
-CAfile arg - PEM format file of CA's
-reconnect - Drop and re-make the connection with the same Session-ID
-pause - sleep(1) after each read(2) and write(2) system call
-showcerts - show all certificates in the chain
-debug - extra output
-msg - Show protocol messages
-nbio_test - more ssl protocol testing
-state - print the 'ssl' states
-nbio - Run with non-blocking IO
-crlf - convert LF from terminal into CRLF
-quiet - no s_client output
-ign_eof - ignore input eof (default when -quiet)
-no_ign_eof - don't ignore input eof
-psk_identity arg - PSK identity
-psk arg - PSK in hex (without 0x)
-srpuser user - SRP authentification for 'user'
-srppass arg - password for 'user'
-srp_lateuser - SRP username into second ClientHello message
-srp_moregroups - Tolerate other than the known g N values.
-srp_strength int - minimal mength in bits for N (default 1024).
-ssl2 - just use SSLv2
-ssl3 - just use SSLv3
-tls1_2 - just use TLSv1.2
-tls1_1 - just use TLSv1.1
-tls1 - just use TLSv1
-dtls1 - just use DTLSv1
-mtu - set the link layer MTU
-no_tls1_2/-no_tls1_1/-no_tls1/-no_ssl3/-no_ssl2 - turn off that protocol
-bugs - Switch on all SSL implementation bug workarounds
-serverpref - Use server's cipher preferences (only SSLv2)
-cipher - preferred cipher to use, use the 'openssl ciphers'
command to see what is available
-starttls prot - use the STARTTLS command before starting TLS
for those protocols that support it, where
'prot' defines which one to assume. Currently,
only "smtp", "pop3", "imap", "ftp" and "xmpp"
are supported.
-engine id - Initialise and use the specified engine
-rand file:file:...
-sess_out arg - file to write SSL session to
-sess_in arg - file to read SSL session from
-servername host - Set TLS extension servername in ClientHello
-tlsextdebug - hex dump of all TLS extensions received
-status - request certificate status from server
-no_ticket - disable use of RFC4507bis session tickets
-nextprotoneg arg - enable NPN extension, considering named protocols supported (comma-separated list)
-legacy_renegotiation - enable use of legacy renegotiation (dangerous)
-use_srtp profiles - Offer SRTP key management with a colon-separated profile list
-keymatexport label - Export keying material using label
-keymatexportlen len - Export len bytes of keying material (default 20)
</pre>

==== ocsp ====

=== Signing / Digest and Timestamping ===

==== Signing / Digest ====

<pre>
openssl dgst --help
unknown option '--help'
options are
-c to output the digest with separating colons
-r to output the digest in coreutils format
-d to output debug info
-hex output as hex dump
-binary output in binary form
-hmac arg set the HMAC key to arg
-non-fips-allow allow use of non FIPS digest
-sign file sign digest using private key in file
-verify file verify a signature using public key in file
-prverify file verify a signature using private key in file
-keyform arg key file format (PEM or ENGINE)
-out filename output to filename rather than stdout
-signature file signature to verify
-sigopt nm:v signature parameter
-hmac key create hashed MAC with key
-mac algorithm create MAC (not neccessarily HMAC)
-macopt nm:v MAC algorithm parameters or key
-engine e use engine e, possibly a hardware device.
-md4 to use the md4 message digest algorithm
-md5 to use the md5 message digest algorithm
-ripemd160 to use the ripemd160 message digest algorithm
-sha to use the sha message digest algorithm
-sha1 to use the sha1 message digest algorithm
-sha224 to use the sha224 message digest algorithm
-sha256 to use the sha256 message digest algorithm
-sha384 to use the sha384 message digest algorithm
-sha512 to use the sha512 message digest algorithm
-whirlpool to use the whirlpool message digest algorithm
</pre>
==== timestamping ====

openssl ts

<pre>
usage:
ts -query [-rand file:file:...] [-config configfile] [-data file_to_hash] [-digest digest_bytes][-md2|-md4|-md5|-sha|-sha1|-mdc2|-ripemd160] [-policy object_id] [-no_nonce] [-cert] [-in request.tsq] [-out request.tsq] [-text]
or
ts -reply [-config configfile] [-section tsa_section] [-queryfile request.tsq] [-passin password] [-signer tsa_cert.pem] [-inkey private_key.pem] [-chain certs_file.pem] [-policy object_id] [-in response.tsr] [-token_in] [-out response.tsr] [-token_out] [-text] [-engine id]
or
ts -verify [-data file_to_hash] [-digest digest_bytes] [-queryfile request.tsq] -in response.tsr [-token_in] -CApath ca_path -CAfile ca_file.pem -untrusted cert_file.pem
</pre>

=== Data handling ===

==== ASN.1 ====

[[DER]] decoding

openssl asn1parse

==== Base64 ====

base64 encoding / decoding

[[Base64]]

===== a String =====

<pre>
openssl base64 -e <<< 'Welcome to openssl wiki'
V2VsY29tZSB0byBvcGVuc3NsIHdpa2kK
openssl base64 -d <<< 'V2VsY29tZSB0byBvcGVuc3NsIHdpa2kK'
Welcome to openssl wiki
</pre>

warning '''base64 line length is limited to 76 characters by default in openssl''' ( and generated with 64 characters / line ).

<pre>
openssl base64 -e <<< 'Welcome to openssl wiki with a very long line that splits...'
V2VsY29tZSB0byBvcGVuc3NsIHdpa2kgd2l0aCBhIHZlcnkgbG9uZyBsaW5lIHRo
YXQgc3BsaXRzLi4uCg==
openssl base64 -d <<< 'V2VsY29tZSB0byBvcGVuc3NsIHdpa2kgd2l0aCBhIHZlcnkgbG9uZyBsaW5lIHRoYXQgc3BsaXRzLi4uCg=='
</pre>
=> NOTHING !

to be able to decode a base64 line without line feed that exceed 76 characters use -A option :

<pre>
openssl base64 -d -A <<< 'V2VsY29tZSB0byBvcGVuc3NsIHdpa2kgd2l0aCBhIHZlcnkgbG9uZyBsaW5lIHRoYXQgc3BsaXRzLi4uCg=='
Welcome to openssl wiki with a very long line that splits...
</pre>

This is anyway better to actualy split base64 result in 64 characters lines since -A option is BUGGY ( limit with long files ).

==== DER <-> PEM conversion ====

on each command handling PEM and DER format an '''inform''' and '''outform''' options are provided to specify it.
Then it is easy to read it in format and write it in another

==== pkcs8 / pkcs5 ====

pkcs8 is a format to store private keys.
pkcs8 uses various pkcs5 version as subformat.

<pre>
openssl pkcs8 --help
Usage pkcs8 [options]
where options are
-in file input file
-inform X input format (DER or PEM)
-passin arg input file pass phrase source
-outform X output format (DER or PEM)
-out file output file
-passout arg output file pass phrase source
-topk8 output PKCS8 file
-nooct use (nonstandard) no octet format
-embed use (nonstandard) embedded DSA parameters format
-nsdb use (nonstandard) DSA Netscape DB format
-noiter use 1 as iteration count
-nocrypt use or expect unencrypted private key
-v2 alg use PKCS#5 v2.0 and cipher "alg"
-v1 obj use PKCS#5 v1.5 and cipher "alg"
-engine e use engine e, possibly a hardware device.
</pre>

=== Diagnostics ===

==== SSL/TLS session information ====

<pre>
openssl sess_id --help
unknown option --help
usage: sess_id args

-inform arg - input format - default PEM (DER or PEM)
-outform arg - output format - default PEM
-in arg - input file - default stdin
-out arg - output file - default stdout
-text - print ssl session id details
-cert - output certificate
-noout - no CRL output
-context arg - set the session ID context
</pre>

[[Category:Shell level]]

MediaWiki:Confirmemail oncreate

2013-04-03T20:11:42Z

Stevem: Use opensslfoundation.com E-mail address

A confirmation code was sent to your e-mail address.
This code is not required to log in, but you will need to provide it before enabling any e-mail-based features in the wiki.

We had to disable default edit privileges due to excessive spam postings.
For edit privileges please contract the administrators at [mailto:wiki-admin@openssl.com wiki-admin@opensslfoundation.com].

MediaWiki:Confirmemail body

2013-04-03T20:11:05Z

Stevem: Use opensslfoundation.com E-mail address

Someone, probably you, from IP address $1,
has registered an account "$2" with this e-mail address on {{SITENAME}}.

To confirm that this account really does belong to you and activate
e-mail features on {{SITENAME}}, open this link in your browser:

$3

If you did *not* register the account, follow this link
to cancel the e-mail address confirmation:

$5

This confirmation code will expire at $4.

Once your account registration is complete you will still not be able to edit content
(thanks to excessive spam abuse). Send an E-mail to wiki-admin@opensslfoundation.com to request
edit privileges. If you're not already a participant in the OpenSSL mailing lists a
brief description of your interest will be appreciated, so we'll know you're a
legitimate member of the OpenSSL community and not a spam artist.

MediaWiki:Confirmemail oncreate

2013-04-03T18:05:20Z

Stevem: Add instructions for requesting edit privileges

MediaWiki:Confirmemail body

2013-04-03T17:51:52Z

Stevem: Add text about edit privileges

Someone, probably you, from IP address $1,
has registered an account "$2" with this e-mail address on {{SITENAME}}.

To confirm that this account really does belong to you and activate
e-mail features on {{SITENAME}}, open this link in your browser:

$3

If you did *not* register the account, follow this link
to cancel the e-mail address confirmation:

$5

This confirmation code will expire at $4.

Once your account registration is complete you will still not be able to edit content
(thanks to excessive spam abuse). Send an E-mail to wiki-admin@openssl.com to request
edit privileges. If you're not already a participant in the OpenSSL mailing lists a
brief description of your interest will be appreciated, so we'll know you're a
legitimate member of the OpenSSL community and not a spam artist.

FIPS mode

2013-03-25T13:38:28Z

Stevem: moved FIPS mode to FIPS mode(): Have page name map function name as closely as possible

#REDIRECT [[FIPS mode()]]

FIPS mode()

2013-03-25T13:38:28Z

Stevem: moved FIPS mode to FIPS mode(): Have page name map function name as closely as possible

----
'''NAME'''

FIPS_mode - retrieve the current FIPS 140-2 mode of operation

----
'''SYNOPSIS'''

#include <openssl/crypto.h>

int FIPS_mode(void);

----
'''DESCRIPTION'''

FIPS_mode() is used to determine the FIPS mode of operation by a program utilizing the services of the validated library. The library must have been built with the FIPS Object Module, and the FIPS Object Module must have been acquired, built, and installed in accordance with the Open''''''SSL Security Policy.

The return value is either 0 to indicate that the FIPS mode of operation is not enabled, or the value used for the ONOFF parameter passed to an earlier successful call to FIPS_mode_set(). Effectively any non-zero value indicates FIPS mode; values other than 1 may have additional significance such as designating an additional restriction to Suite B algorithms.

If the library was built without support of the FIPS Object Module, then the function will return 0 with an error code of CRYPTO_R_FIPS_MODE_NOT_SUPPORTED (0x0f06d065).

----
'''RETURN VALUES'''

A return code of non-zero indicates FIPS mode, 0 indicates non-FIPS mode. When called from a version of Open''''''SSL that is not "FIPS capable" (capable of utilizing an embedded FIPS Object Module), then FIPS_mode() will always return 0.

----
'''SEE ALSO'''

FIPS_mode_set(3), FIPS_selftest(3)

----
'''NOTES'''

FIPS_mode() was formerly included with <openssl/fips.h>.

----
'''HISTORY'''

FIPS support was introduced in version 0.9.7 of Open''''''SSL.

FIPS mode()

2013-03-25T13:37:12Z

Stevem: raw output from pod2wiki

----
'''NAME'''

FIPS_mode - retrieve the current FIPS 140-2 mode of operation

----
'''SYNOPSIS'''

#include <openssl/crypto.h>

int FIPS_mode(void);

----
'''DESCRIPTION'''

FIPS_mode() is used to determine the FIPS mode of operation by a program utilizing the services of the validated library. The library must have been built with the FIPS Object Module, and the FIPS Object Module must have been acquired, built, and installed in accordance with the Open''''''SSL Security Policy.

The return value is either 0 to indicate that the FIPS mode of operation is not enabled, or the value used for the ONOFF parameter passed to an earlier successful call to FIPS_mode_set(). Effectively any non-zero value indicates FIPS mode; values other than 1 may have additional significance such as designating an additional restriction to Suite B algorithms.

If the library was built without support of the FIPS Object Module, then the function will return 0 with an error code of CRYPTO_R_FIPS_MODE_NOT_SUPPORTED (0x0f06d065).

----
'''RETURN VALUES'''

A return code of non-zero indicates FIPS mode, 0 indicates non-FIPS mode. When called from a version of Open''''''SSL that is not "FIPS capable" (capable of utilizing an embedded FIPS Object Module), then FIPS_mode() will always return 0.

----
'''SEE ALSO'''

FIPS_mode_set(3), FIPS_selftest(3)

----
'''NOTES'''

FIPS_mode() was formerly included with <openssl/fips.h>.

----
'''HISTORY'''

FIPS support was introduced in version 0.9.7 of Open''''''SSL.

FIPS mode set()

2013-03-25T12:10:46Z

Stevem: Example of "pod2wiki FIPS_mode_set.pod"

The FIPS_mode_set(3) function has the following prototype: int FIPS_mode_set(int onoff);

when set to non-zero you go into FIPS mode.
when set to zero you go into non-FIPS mode.

[[Category:FIPS 140]]
[[Category:C level]]
[[Category:Crypto API]]

----
'''NAME'''

FIPS_mode - enter or exit FIPS 140-2 mode of operation

----
'''SYNOPSIS'''

#include <openssl/crypto.h>

int FIPS_mode_set(int ONOFF);

----
'''DESCRIPTION'''

FIPS_mode_set() is used to set the FIPS mode of operation of a running program utilizing the services of a validated library. The library must have been built with the FIPS Object Module, and the FIPS Object Module must have been acquired, built, and installed in accordance with the Open''''''SSL Security Policy.

When invoked with non-zero value for ONOFF value, FIPS_mode_set() will attempt to enter FIPS mode of operation. If the FIPS Object Module successfully enters FIPS mode, the function will return that non-zero value.

Currently all non-zero values of ONOFF enable FIPS mode. In the future other values may specify additional actions beyond enabling FIPS mode, such as a value of 2 to designate an additional restriction to Suite B algorithms. To avoid further compatibility issues, a program is encouraged to call FIPS_mode_set() with a ONOFF value of 1 (rather than an arbitrary non-zero value).

During a call to FIPS_mode_set() with a non-zero value of ONOFF, a number of tests are performed. See FIPS_selftest() for details on the testing performed by the validated FIPS Object Module.

When invoked with ONOFF value of 0, FIPS_mode_set() will attempt to exit the FIPS mode of operation. If the FIPS Object Module successfully exits FIPS mode, the function will return 1.

If FIPS_mode_set() returns a value of 0, then the request to enter or exit the FIPS mode of operation failed. In this case, the caller should call ERR_get_error() to retrieve the error code associated with the failure. The error code can later be used by ERR_error_string(<err>) or `openssl errstr <err>' for a readable string.

FIPS_mode_set() can fail for a number of reasons, and many of the error codes are discussed in detail in the Open''''''SSL FIPS Object Module User Guide 2.0. One common code is CRYPTO_R_FIPS_MODE_NOT_SUPPORTED (0xf06d065). The particular error code indicates the application was likely linked against an Open''''''SSL library without validated cryptography. That is, a FIPS Capable Library was *not* used during application linking.

----
'''RETURN VALUES'''

A non-zero return value indicates success, 0 failure.

----
'''EXAMPLE'''

int mode = FIPS_mode(), ret = 0; unsigned long err = 0;

/* Toggle FIPS mode */ if(mode == 0) { ret = FIPS_mode_set(1 /*on*/); if(ret != 1) { err = ERR_get_error(); } } else { ret = FIPS_mode_set(0 /*off*/); if(ret != 1) { err = ERR_get_error(); } }

if(ret != 1) printf("FIPS_mode_set failed: %lx.", err);

----
'''SEE ALSO'''

FIPS_mode(3), FIPS_selftest(3), ERR_get_error(3), ERR_error_string(3), openssl(8)

----
'''NOTES'''

FIPS_mode_set() was formerly included with <openssl/fips.h>.

----
'''HISTORY'''

FIPS support was introduced in version 0.9.7 of Open''''''SSL.

OpenSSLWiki:Copyrights

2013-03-18T12:21:44Z

Stevem: Add redirect to :License

#REDIRECT [[License]]

MediaWiki:Copyrightwarning

2013-03-18T12:20:42Z

Stevem: Hmmm, back like it was

Please note that all contributions to {{SITENAME}} are considered to be released under the current or future $2: see $1 for details.
If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource, or from OpenSSL.
'''Do not submit copyrighted work without permission!'''

MediaWiki:Copyrightwarning

2013-03-18T12:17:33Z

Stevem:

Please note that all contributions to {{SITENAME}} are considered to be released under the current or future $2: see [[License]] for details.
If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource, or from OpenSSL.
'''Do not submit copyrighted work without permission!'''