FIPS module 3.0 - Revision history

Tjh: remove historical information that is out of date

2018-10-01T02:12:02Z

remove historical information that is out of date

Tjh: Update the old plans to be something closer to what the current plans are for the next FIPS module

2018-03-14T09:31:15Z

Update the old plans to be something closer to what the current plans are for the next FIPS module

Tjh at 03:55, 31 December 2017

2017-12-31T03:55:46Z

Stevem: Added sponsorship info

2016-10-31T14:52:52Z

Added sponsorship info

Stevem: Added anti-goals

2016-09-27T13:34:55Z

Added anti-goals

Stevem: typo

2016-09-27T13:20:50Z

typo

Stevem: Caveat entropy goal

2016-09-19T13:39:22Z

Caveat entropy goal

Stevem: Initial draft

2016-09-19T13:17:10Z

Initial draft

New page

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) 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

@@ Line 1: / Line 1: @@
-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.
+The 3.0 FIPS module will be conceptually different to the preceeding line of ''OpenSSL FIPS Object Module'' cryptographic modules.
 == Note ==
-These notes are old and subject to change going forward.
+These notes are subject to change going forward.
-What we probably won't do:
+What we won't do:
 . Any "light" or other versions of the FIPS module (i.e fewer algorithm implementations).
-. Matching set of platforms. The initial validation will only include a minimal platform set.
+. Matching set of platforms. The initial validation will only include a very minimal platform set.
 . Any substantial additions or changes to the module once the initial development is substantially complete.

@@ Line 1: / Line 1: @@
 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 ==
+These notes are old and subject to change going forward.
-:{| style="height=5em; border-spacing: 0px;"
+== Draft Technical Objectives ==

← Older revision		Revision as of 14:52, 31 October 2016
Line 1:		Line 1:
	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.		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:		An initial rough draft of requirements and goals:

← Older revision		Revision as of 13:34, 27 September 2016
Line 60:		Line 60:

	l. XTS-AES compliance to I.G. A.9		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).

@@ Line 5: / Line 5: @@
 These notes are old and subject to change going forward.
-== Draft Technical Objectives ==
+. Any "light" or other versions of the FIPS module (i.e fewer algorithm implementations).
-An initial rough draft of requirements and goals:
+. Any substantial additions or changes to the module once the initial development is substantially complete.
-) 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.
+== Draft Technical Objectives ==
-) Consider feasibility of built in entropy sources so OpenSSL or the parent application/library aren't required to supply entropy.
+An initial rough draft of requirements and goals:
-) 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).
+) Keep it minimal and fully usable as a stand alone crypto module.
-) Ability to build out of the source tree.
+) FIPS 186-4 KeyGen.
-) FIPS 186-4 KeyGen.
+) 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.
 ) SP 800-56B vendor affirmation (I.G. D.4).
 ) SHA-3 and SHAKE.
 ) Automatic execution of power-on self-tests (I.G. 9.5/9.10).
-) Any allowed efficiencies in power-on self-tests.
+) Consider any newly FIPS approved algorithms (e.g. new EC curves, Chacha/Poly)
-) Explore possibility of validating "stitched" algorithm implementations.
+== Previous Stakeholder Requests ==
-) Consider any newly FIPS approved algorithms (e.g. new EC curves, Chacha/Poly)
+Note: none of these are committed as yet.
 a.	RSA key wrapping as part of NIST SP 800-56B (also called KTS validation testing), if CAVS testing is available.
@@ Line 68: / Line 63: @@
 l.	XTS-AES compliance to I.G. A.9

@@ Line 57: / Line 57: @@
 j.	SP 800-108 KDFs
-l.	Addition of AES XPN
+k.	Addition of AES XPN
-m.	XTS-AES compliance to I.G. A.9
+l.	XTS-AES compliance to I.G. A.9

@@ Line 9: / Line 9: @@
 ) 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).
-) Built in entropy sources so OpenSSL or the parent application/library aren't required to supply entropy.
+) Consider feasibility of built in entropy sources so OpenSSL or the parent application/library aren't required to supply entropy.
 ) 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).