Validation Notes
AES
Implementations have been validated as conforming to the Advanced Encryption Standard (AES) Algorithm, as specified in Federal Information Processing Standard Publication 197, Advanced Encryption Standard, using the tests found in the Advanced Encryption Standard Algorithm Validation Suite (AESAVS).
CCM
Implementations have been validated as conforming to the Counter with Cipher Block Chaining-Message Authentication Code (CCM), as specified in Special Publication 800-38C, using tests described in the CCM Validation System (CCMVS).
Component
Implementations have been validated as conforming to individual components of FIPS approved and NIST recommended cryptographic algorithms, as specified in the associated publications, using tests described in the associated validation system (VS) documents.
As of January 1, 2016, in accordance with the SP800-131A Revision 1 Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths and the CMVP Implementation Guidance (IG) W.2 Validating the Transition from FIPS 186-2 to FIPS 186-4, the use of modulus and curve sizes providing less than 112 bits of security strength (modulus size 1024 and curve sizes P-192, K-163, and B-163), and the use of SHA-1 with Digital Signature Generation, is no longer approved.
Formerly validated implementation capabilities that are no longer approved are identified by strikethrough text.
DES
Implementations have been validated as conforming to the Data Encryption Standard (DES) algorithm, as specified in Federal Information Processing Standard (FIPS) 46-3, Data Encryption Standard (DES) and FIPS 81, DES Modes of Operation, using tests described in the NIST Special Publication 800-17, Modes of Operation Validation System (MOVS): Requirements and Procedures.
As of May 19, 2007, in accordance with the DES Transition Plan, the use of DES is no longer approved. This list is provided for historical purposes only.
DRBG
Implementations have been validated as conforming to the Deterministic Random Bit Generator (DRBG) Algorithm, as specified in Special Publication 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, using tests described in the DRBG Validation Suite (DRBGVS).
As of June 2015, in accordance with SP800-90A Revision 1, and November 2015, in accordance with SP800-131A Revision 1, the use of Dual_EC_DRBG is no longer approved.
Formerly validated implementation capabilities that are no longer approved are identified by strikethrough text.
DSA
Implementations have been validated as conforming to the Digital Signature Algorithm (DSA), as specified in Federal Information Processing Standard (FIPS) 186-2 with Change Notice 1 and FIPS 186-4, using tests described in the (186-2) Digital Signature Algorithm Validation System (DSAVS) and (186-4) Digital Signature Algorithm Validation System (DSA2VS).
As of May 19, 2007, in accordance with the SP 800-57 Transition Plan, the use of modulus sizes providing less than 80 bits of security strength is no longer approved.
As of January 1, 2016, in accordance with the SP800-131A Revision 1 Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths and the CMVP Implementation Guidance (IG) W.2 Validating the Transition from FIPS 186-2 to FIPS 186-4, the use of modulus sizes providing less than 112 bits of security strength, and the use of SHA-1 with Digital Signature Generation excluding use with protocols, is no longer approved.
As of January 1, 2016, in accordance with the SP800-131A Revision 1 Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, the use of RNGs specified in FIPS 186-2, [X9.31], and the 1998 version of [X9.62] as a prerequisite for validation testing is no longer approved.
Formerly validated implementation capabilities that are no longer approved are identified by strikethrough text.
ECDSA
Implementations have been validated as conforming to the Elliptic Curve Digital Signature Algorithm (ECDSA), as specified in Federal Information Processing Standard (FIPS) 186-2 with Change Notice 1 and FIPS 186-4, using tests described in the (186-2) Elliptic Curve Digital Signature Algorithm Validation System (ECDSAVS) and (186-4) Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS).
As of January 1, 2016, in accordance with the SP800-131A Revision 1 Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths and the CMVP Implementation Guidance (IG) W.2 Validating the Transition from FIPS 186-2 to FIPS 186-4, the use of curve sizes providing less than 112 bits of security strength (P-192, K-163, and B-163), and the use of SHA-1 with Digital Signature Generation excluding use with protocols, is no longer approved.
As of January 1, 2016, in accordance with the SP800-131A Revision 1 Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, the use of RNGs specified in FIPS 186-2, [X9.31], and the 1998 version of [X9.62] as a prerequisite for validation testing is no longer approved.
Formerly validated implementation capabilities that are no longer approved are identified by strikethrough text.
HMAC
Implementations have been validated as conforming to the Keyed-Hash Message Authentication Code (HMAC), as specified in Federal Information Processing Standard (FIPS) 198, Keyed-Hash Message Authentication Code (HMAC), using tests described in the Keyed-Hash Message Authentication Code (HMAC) Validation Suite (HMACVS).
KAS
Implementations have been validated as conforming to the Key Agreement Schemes and/or Key Confirmation using Finite Field Cryptography (FFC) or Elliptic Curve Cryptography (ECC), as specified in SP 800-56A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, using tests described in the KAS Validation System (KASVS).
As of January 1, 2016, in accordance with the SP800-131A Revision 1 Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths dated November 2015, the use of SP 800-56A DH and MQV key agreement schemes using finite fields |p| = 1024 bits and |q| = 160 bits, and the use of SP 800-56A DH and MQV key agreement schemes using elliptic curves with |n| less than or equal to 223 bits, is no longer approved.
Formerly validated implementation capabilities that are no longer approved are identified by strikethrough text.
KDF
Implementations have been validated as conforming to the key-based key derivation functions, as specified in Special Publication 800-108 Recommendation for Key Derivation Using Pseudorandom Functions (Revised), using tests described in the SP800-108 Key Derivation Function Validation System (KBKDFVS).
As of January 1, 2016, in accordance with the SP800-131A Revision 1 Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths dated November 2015, the use of two-key TDEA for the derivation of keying material in a CMAC-based KDF is no longer approved.
As of January 1, 2016, in accordance with the SP800-131A Revision 1 Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths dated November 2015, the use of RNGs specified in FIPS 186-2, [X9.31] and the 1998 version of [X9.62] as a prerequisite for validation testing is no longer approved.
Formerly validated implementation capabilities that are no longer approved are identified by strikethrough text.
RNG
Implementations have been validated as conforming to the various Random Number Generators (RNG) as specified in Federal Information Processing Standard (FIPS) 186-2, Digital Signature Standard (DSS), ANSI X9.62-1998, Public Key Cryptography for the Financial Services Industry: Elliptic Curve Digital Signature Algorithm (ECDSA), and ANSI X9.31-1998, Digital Signatures Using Reversible Public Key Cryptography for the Financial Services Industry (rDSA), using tests described in the Random Number Generator Validation System (RNGVS).
As of January 1, 2016, in accordance with the SP800-131A Revision 1 Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, the use of RNGs specified in FIPS 186-2, [X9.31], and the 1998 version of [X9.62] is no longer approved. This list is provided for historical purposes only.
RSA
Implementations have been validated as conforming to the RSA algorithm, as specified in Federal Information Processing Standard (FIPS) 186-2 with Change Notice 1 and FIPS 186-4, using tests described in (186-2) The RSA Validation System (RSAVS) and The 186-4 RSA Validation System (RSA2VS).
As of January 1, 2016, in accordance with the SP800-131A Revision 1 Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths and the CMVP Implementation Guidance (IG) W.2 Validating the Transition from FIPS 186-2 to FIPS 186-4, the use of modulus sizes providing less than 112 bits of security strength (1024 and 1536) in digital signature generation, and the use of SHA-1 with Digital Signature Generation excluding use with protocols, is no longer approved.
As of January 1, 2016, in accordance with the SP800-131A Revision 1 Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, the use of RNGs specified in FIPS 186-2, [X9.31], and the 1998 version of [X9.62] as a prerequisite for validation testing is no longer approved.
Formerly validated implementation capabilities that are no longer approved are identified by strikethrough text.
In October of 2017 it was discovered that CAVS was testing for the wrong algorithm identifier for SHA-512/256 as part of the ANS X9.31 padding scheme for RSA signature generation and verification. The incorrect byte value of "0x40" was used instead of the correct value of "0x3a". The testing of the incorrect value is purely an interoperability concern, meaning that differing implementations may not be able to correctly verify signatures generated using different algorithm identifiers, and this error has no impact on the security of the signatures relative to the choice of algorithm identifiers.
In order to not invalidate any existing long-lived signatures by prior implementations, CAVP will permit implementations to verify signatures with the "0x40" algorithm identifier, and in order to interoperate with systems using the incorrect algorithm identifier implementations may choose to generate signatures with the "0x40" algorithm identifier. Both of these options are considered deprecated and will not be tested for by the CAVP program but neither will they be disallowed.
For the ANS X9.31 padding scheme implementations will be annotated with the SHA-512/256 algorithm identifier they were tested for which is either "0x40" or "0x3a". All future implementations will only be tested for the correct value of "0x3a" going forward.
SHA-3
Implementations have been validated as conforming to the SHA-3 family of functions, as specified in Federal Information Processing Standard (FIPS) 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, using the tests found in the Secure Hash Algorithm-3 Validation Suite (SHA3VS).
SHS
Implementations have been validated as conforming to the Secure Hash Algorithms specified in Federal Information Processing Standard (FIPS) 180-4, Secure Hash Standard (SHS), using tests described in the Secure Hash Algorithm Validation System (SHAVS).
Skipjack
Implementations have been validated as conforming to the Skipjack algorithm, as specified in Federal Information Processing Standard (FIPS) 185, Escrowed Encrypytion Standard (EES) and FIPS 81, DES Modes of Operation, using tests described in the NIST Special Publication 800-17, Modes of Operation Validation System (MOVS): Requirements and Procedures.
TDES
Implementations have been validated as conforming to the Triple Data Encryption Algorithm (TDEA, a.k.a. "Triple DES"), as specified in Federal Information Processing Standard (FIPS) 46-3, Data Encryption Standard (DES) and ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation, using the tests found in NIST Special Publication 800-20, Modes of Operation Validation System for the Triple Data Encryption Algorithm (TMOVS): Requirements and Procedures.
As of May 19, 2007, in accordance with the DES Transition Plan, Triple DES keying option 3 (Key 1 = Key 2 = Key 3) is no longer approved.
As of January 1, 2016, in accordance with the SP800-131A Revision 1 Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths dated November 2015, the use of two-key TDEA for encryption is no longer approved. Decryption using two-key TDEA is allowed for legacy use only.
Formerly validated implementation capabilities that are no longer approved are identified by strikethrough text.
) or https:// don't prove our archive is authentic, only that you securely accessed it. Note that we are working to fix that :)
