FIPS module 3.0

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

l. Addition of AES XPN

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