Search
CSRC:

NIST, Computer Security Division, Computer Security Resource
Center

about

mission

contact

staff

site
map

csrc home

groups

Cryptographic
Technology

Systems & Emerging
Technologies Security Research

Security Management &
Assurance

publications

Draft
Publications

FIPS
Publications

Special
Publications

NIST Interagency
Reports

ITL Security
Bulletins

Archived FIPS
Publications

Archived Special
Publications

List by Topic
Clusters

List by Family

by Legal
Requirement

drivers

news & events

News

News
Archive

Events

archive

CAVP

Symmetric Key - includes
AES, TDES

Additional Modes of
Operation - includes XTS-AES

Asymmetric Key - includes
DSA (both FIPS 186-2 and FIPS 186-3), ECDSA (both FIPS 186-2 and FIPS
186-3), RSA (both FIPS 186-2 and FIPS 186-3)

SHS

RNG

DRBG

Key
Management - Key Agreement Schemes and Key Confirmation (KAS)

MAC -
includes CMAC, CCM, GCM/GMAC, HMAC

KDF -
includes SP800-108

Component Testing: includes
component testing for SP800-135 KDFs, SP800-56A ECCCDH Primitive Testing,
FIPS 186-3 ECDSA Signature Generation Primitive Testing, FIPS 186-3 RSA
PKCS1.5 and PKCS PSS Signature Generation Primitive Testing

Announcements

Notices

Standards

Validation
Lists

Contacts

CAVP
Management Manual and FAQs

CAVP Announcements

[12-18-12]
-- New release of the CAVS algorithm validation testing tool to the CST
Laboratories (CAVS14.2). This version of the CAVS tool address several minor
updates. For more information, please go to the Announcements page.

[10-02-12]
-- New release of the CAVS algorithm validation testing tool to the CST
Laboratories (CAVS14.1). This version of the CAVS tool address several minor
updates. For more information, please go to the Announcements
page.

more
announcements

CAVP Notices

[09-06-12]
-- GMAC implementation error reported by 3rd party in Open SSL FIPS
Object Module (Cert. #1747) Version 2.0 (AES Cert. #1884) and Version 2.0.1
(AES Cert. #2116)

more
notices

CSRC Home >

Groups >

STM >

CAVP

Cryptographic Algorithm Validation Program (CAVP)

The Cryptographic Algorithm Validation Program (CAVP)
encompasses validation testing for FIPS approved and NIST recommended
cryptographic algorithms and components of algorithms. Cryptographic algorithm
validation is a prerequisite to the Cryptographic Module Validation Program
(CMVP). The CAVP was established by NIST and the Communications Security
Establishment Canada (CSEC) in July 1995. All of the tests under the CAVP are
handled by third-party laboratories that are accredited as Cryptographic and
Security Testing (CST) Laboratories by the National Voluntary Laboratory
Accreditation Program (NVLAP). Vendors interested in validation testing of their
algorithm implementation may select any of the accredited laboratories.

Cryptographic Algorithm Validation Testing Specifications

Below are the algorithms for which the CAVP currently has validation testing.
Each section consists of links to the cryptographic algorithm standard, the
algorithm validation test suite specifications (the Validation System document),
the algorithm validation list, and the test vectors to informally verify the
correctness of an algorithm implementation.

Symmetric Key

Advanced Encryption Standard (AES), Triple-DES, and Skipjack Algorithms

Currently, there exist three FIPS-approved symmetric key algorithms for
encryption: Advanced Encryption Standard (AES),
Triple-DES, and Skipjack. AES is the
FIPS-Approved symmetric encryption algorithm of choice.

FIPS 197, Advanced Encryption Standard (AES),
specifies the AES algorithm.

Recommendation for the Triple Data Encryption Algorithm (TDEA) Block
Cipher, NIST Special Publication 800-67, January 2012.

Recommendation for Block Cipher Modes of Operation, Methods and
Techniques, Special Publication 800-38A, December 2001. Appendix E
references Modes of Triple-DES.

Triple Data Encryption Algorithm Modes of Operation, ANSI
X9.52-1998. Copies of X9.52-1998 may be obtained from X9, a standards committee for the financial services
industry. NIST does NOT have copies of the standard available
for distribution.

The Skipjack algorithm is referenced in FIPS 185, Escrowed Encryption Standard (EES), and a
complete specification is available in SKIPJACK and KEA Algorithm Specifications (Version 2.0, 29
May 1998).

Testing Requirements:

Validation testing for AES, Triple-DES, and Skipjack algorithms are handled
by the Cryptographic Algorithm Validation Program's (CAVP) CST labs.

AES tests are described in The Advanced Encryption Standard Algorithm Validation Suite
(AESAVS).

Triple-DES tests are described in NIST Special Publication 800-20, Modes of Operation Validation System for the
Triple Data Encryption Algorithm (TMOVS): Requirements and Procedures. An
additional test, the Multi-block
Message Text (MMT), is also required.

Additional testing note: The AES and TDES Counter Mode
requires additional prerequisite testing of the underlying symmetric algorithm
using any mode of operation that utilizes the forward cipher function.

Skipjack tests: As of January 2011, the CAVP only validates Skipjack
decryption implementations. Please see SP800-131A Transitions: Recommendation for Transitioning the Use
of Cryptographic Algorithms and Key Lengths for more information.

The Skipjack tests for the decrypt state are described in NIST
Special Publication 800-17, Modes of Operation Validation System (MOVS):
Requirements and Procedures. The validation test suite for Skipjack
implementations using the decrypt state consists of the Modes test for the
Decryption Process, the Variable Ciphertext Known Answer Test and the Variable
Key Known Answer Test for the Decryption Process. Based on the Skipjack modes
of operation implemented, SP800-17 Section 5 indicates the tests required to
validate an implementation of the Skipjack Algorithm.

(NIST
Special Publication 800-17 erroneously states the Initial Permutation KAT for
the Decryption Process is also required for Skipjack validation. This is not
true.)

Validation List:

NIST maintains validation lists for AES, Triple-DES, and Skipjack. These lists identify the algorithm implementations
which have been tested as correctly implementing the AES, Triple-DES, and
Skipjack algorithms. Points of contact and implementation descriptions are also
included.

Test Vectors:

The following files provide electronic versions of the vectors for the Known
Answer Test (KAT), and sample values for the Monte Carlo(MCT) test, and the
Multiblock Message (MMT) test. These values are properly formatted in response
(.rsp) files. Vendor response files should match this format exactly.

In addition, a file with intermediate results (.txt) for the Monte Carlo test
is supplied. The Monte Carlo tests consist of 400 cases. For each case, initial
values are provided, and 10,000 iterations of the desired mode of operation are
run. The output of each iteration is used as input to the next iteration. To aid
debugging, we provide the output for each of the first five (5) iterations of
the 10,000 as well as the final (10,000th) output. The intermediate values are
indented by one tab and clearly identified by use of the word
"Intermediate".

These vectors can be used to informally verify the correctness of an AES
and/or TDES algorithm implementation. The validation system documents (see
above) describe the details of the tests.

NOTE, use of these vectors does not take the place of validation
obtained through the Cryptographic Algorithm Validation Program (CAVP).

Test Vectors for AES:

AES Known Answer Test (KAT) Vectors

AES Monte Carlo Test (MCT) Sample Vectors

AES Monte Carlo Test (MCT) Intermediate Values

AES Multiblock Message Test (MMT) Sample Vectors

Test Vectors for TDES:

Triple DES Known Answer Test (KAT) Vectors

Triple-DES Monte Carlo Test (MCT) Sample Vectors

Triple-DES Monte Carlo Test (MCT) Intermediate Values

Triple-DES Multiblock Message Test (MMT) Sample Vectors

Back to
Top

Additional Modes of Operation for Symmetric Algorithms

XTS-AES

Currently, there exist multiple modes of operation that are described in the
NIST Special Publication 800-38 series. Most of these modes of operation are
message authentication codes and therefore have been listed under the MAC
section. XTS-AES is more like the original modes of operation and therefore is
described below.

NIST SP 800-38E, Recommendation for Block Cipher Modes
of Operation: The XTS-AES Mode for Confidentiality on Block-Oriented Storage
Devices, specifies the XTS-AES algorithm.

Testing Requirements:

Validation testing for XTS-AES mode of operation algorithm is handled by the
Cryptographic Algorithm Validation Program's (CAVP) CST labs.

XTS-AES tests are described in The XTS-AES Validation System (XTSVS).

Validation List:

NIST maintains the current XTS-AES Validations. XTS-AES validations are
included on the AES Validation List.

Other Information:

XTS-AES Test Vectors - This file provides an electronic
version of the test vectors that can be used to informally verify the
correctness of an XTS-AES algorithm implementation, using the validation tests
described in The XTS-AES Validation System (XTSVS). However, use
of these vectors does not take the place of validation obtained through the
Cryptographic Algorithm Validation Program (CAVP).

Back to Top

Asymmetric Key

FIPS 186-3 Digital Signature Standard (DSS) (DSA, RSA, and ECDSA
algorithms)

On June 10, 2009, NIST announced the adoption of FIPS 186-3, Digital Signature Standard (DSS), which
is a revision of FIPS 186-2. The FIPS specifies three techniques for the
generation and verification of digital signatures:

Digital Signature Algorithm (DSA),

RSA (as specified in ANSI X9.31 (RSA)), and

Elliptic Curve DSA (ECDSA; as specified in ANSI X9.62).

FIPS 186-3 allows the use of any random number generator (RNG) or random bit
generator (RBG) that is approved for use in FIPS 140-validated modules, subject
to the transition schedule specified in SP 800-131A. Specific references to SP
800-90 should not be considered as a requirement to use a generator specified in
SP 800-90 until such time as the use of the other generators is no longer
allowed.

FIPS 186-3 incorporates the following
changes:

General:

Specifies the use of all hash functions specified provided in FIPS 180-3,
rather than just SHA-1,

Provides requirements for obtaining assurances of domain parameter
validity (DSA and ECDSA only), public key validity, and private key
possession,

References SP 800-57 for guidance on key management, including the key
sizes and security strengths to be used,

Provides guidance on domain parameter and key pair management,

Provides more guidance on the use of RNGs to generate key pairs,

Provides revised primality test guidance.

DSA:

Specifies larger key sizes,

Replaces the domain parameter generation routine with new methods,

Includes explicit methods for the validation of domain
parameters,

RSA:

Approves the use of both ANSI X9.31 and PKCS #1, and provides guidance for
their use,

Provides multiple explicit methods for the generation of key pairs,

Limits the key sizes and provides criteria for the generation of key pairs
to be used for Federal government use.

ECDSA:

Although the Recommended Elliptic Curves continue to be included in FIPS
186-3 (as they were in FIPS 186-2), FIPS 186-3 allows the generation of
alternative curves, using methods specified in ANS X9.62.

Copies of the ANSI X9.31 and ANSI X9.62
standards are available from X9, a standards committee accredited by the American National
Standards Institute (ANSI). NIST does NOT have copies of these standards
available for distribution.

All three digital signature techniques in FIPS 186-3 make use of the Secure
Hash Algorithms specified in FIPS 180-3 dated October 2008, Secure Hash
Standard (SHS) accessible via the hashing section of this webpage.

FIPS 186-2 and FIPS 186-3 are currently the only FIPS standards that
contain Approved methods for digital signatures.

Testing Requirements:

CST
labs can test for conformance to the algorithm specifications in FIPS 186-3
for the DSA, ECDSA, and RSA algorithms.

The algorithm validation testing requirements for FIPS 186-3 DSA are
specified in:

Digital Signature Algorithm Validation System
(DSA2VS)
Additional testing note: For the
Domain Parameter Generation and Verification, and the Signature Generation and
Verification functions, the underlying SHA algorithm must be validated as part
of the DSA validation. In addition, Signature Generation and Key Pair Generation
require the RNG/DRBG algorithm to be validated as well.

The algorithm validation testing requirements for FIPS 186-3 ECDSA are
specified in:

Elliptic Curve Digital Signature Algorithm Validation
System (ECDSA2VS)
Additional testing note: As
part of the ECDSA validation, additional algorithms implemented by the ECDSA
algorithm must be validated. For the Key Pair Generation function, this includes
the underlying RNG/ DRBG algorithm. For the Signature Generation function, the
underlying SHA and the RNG/DRBG algorithms must be validated. For the Signature
Verification function, the underlying SHA algorithm must be validated.

The algorithm validation testing requirements for FIPS 186-3 RSA are
specified in:

186-3 RSA Validation System
(186-3RSAVS)
Additional testing note: The
underlying SHA algorithm must be validated as part of the 186-3 RSA validation
for all functions - Key Generation, Signature Generation, and Signature
Verification.. In addition, Key Generation requires the RNG/DRBG algorithm to be
validated as well.

FIPS 186-2 Digital Signature Standard (DSS) (DSA, RSA, and ECDSA
algorithms)

On February 15, 2000, NIST announced the approval of FIPS 186-2 with Change Notice 1 dated October 5,
2001, Digital Signature Standard (DSS), which supersedes FIPS
186-1. This standard specifies three FIPS-approved algorithms for generating and
verifying digital signatures:

Digital Signature Algorithm (DSA),

RSA (as specified in ANSI X9.31), and

Elliptic Curve DSA (ECDSA; as specified in ANSI X9.62).

New items in the DSS include:

the approval of Elliptic Curve DSA (ECDSA) as specified in ANSI X9.62,

a list of recommended elliptic curves for Federal Government use (see
Appendix 6 of FIPS 186-2 with Change Notice 1 dated October 5,
2001), and

an allowance for the continued acquisition of implementations of
PKCS#1 for a transition period of eighteen (18) months.

Copies of the ANSI X9.31 and ANSI X9.62
standards are available from X9, a standards committee accredited by the American National
Standards Institute (ANSI). NIST does NOT have copies of these standards
available for distribution.

All three digital signature techniques in FIPS 186-2 (with Change Notice 1
dated October 5, 2001) make use of the Secure Hash Algorithms specified in FIPS
180-3 dated October 2008, Secure Hash Standard (SHS) accessible via the
hashing section of this webpage.

DSA, RSA, and ECDSA are currently the only FIPS-approved methods for
digital signatures.

Testing Requirements:

CST
labs can test for conformance to the algorithm specifications in FIPS 186-2
(with Change Notice 1 dated October 5, 2001). Algorithm specifications included
in this standard are the DSA, the RSA and the ECDSA algorithms. In addition,
NIST can test for conformance to two other versions of the RSA algorithm
specified in PKCS#1 v2.1: RSA Cryptography Standard, RSA Laboratories, June
2002.

The testing requirements are specified in:

Digital Signature Algorithm Validation System
(DSAVS)
Additional testing note: For the Domain
Parameter Generation and Verification, and the Signature Generation and
Verification functions, the underlying SHA-1 algorithm must be validated as part
of the DSA validation.

RSA Validation System
(RSAVS)
Beginning September 28, 2006:
Validation testing for RSA algorithm implementations of the RSASSA-PKCS1-v1_5,
as specified in Public Key Cryptography Standards (PKCS) #1 v2.1: RSA
Cryptography Standard-2002, and the RSA X9.31 algorithms include additional
testing to assure the encoded message EM and the intermediate integer IR are in
the correct formats. This testing verifies that an implementation under test
(IUT) does not contain a potential implementation design that could introduce a
vulnerability in these algorithms. This testing has been added to the Signature
Verification validation test described in the RSAVS document. No modification to
this document was necessary to add this feature. Below in the Test Vectors
section, there are test vectors available to informally test if this
vulnerability exists in an implementation.

For all validated cryptographic modules that incorporate RSA, the CAVP and
CMVP strongly suggest re-testing of the RSA algorithmic implementations to
determine if the vulnerability is present.

If new CAVP testing is performed and the vulnerability is determined not to
be present, the CSTL can submit the new test results to the CAVP along with a
letter indicating that the implementation passed the RSA testing in CAVS5.2 and
the vulnerability is not present. The letter should request that a new algorithm
certificate be printed to replace the already issued certificate referencing the
new version of CAVS. Please indicate the already issued certificate number. This
letter should be included in the zip file along with the other files. Note that
the certificate number will not change. Only the reference to the version of the
CAVS tool and the signatory date will be changed. (Note the validation request
will be submitted using already established procedures.)

If CAVP testing is performed and the vulnerability is discovered, the
following revalidation process shall be followed:

The algorithm implementation is changed to remove the vulnerability
resulting in a different version number,

Submit the new test results to the CAVP for the new version of the
implementation. A new algorithm certificate will be issued for the new version
of the implementation. The certificate will reference CAVS5.2.

Additional testing note: For the RSA functions, all
underlying SHA algorithm(s) supported by the RSA implementation must be
validated as part of the RSA validation.

Elliptic Curve Digital Signature Algorithm (ECDSA)
Validation System (ECDSAVS)
Additional testing
note: For the Signature Generation and Verification functions, the
underlying SHA-1 algorithm must be validated as part of the ECDSA
validation.

Validation Listings:

NIST maintains the current DSA, ECDSA, and RSA Validation Lists.

DSA Validation List

RSA Validation List

ECDSA Validation List

Test Vectors:

The following files provide an electronic version of the test vectors that
can be used to informally verify the correctness of the FIPS 186-2 and FIPS
186-3 algorithm implementation using the associated validation system document
(DSAVS, ECDSAVS, or RSAVS, DSA2VS, ECDSA2VS, or 186-3RSAVS). These values are
properly formatted in response (.rsp) files. Vendor response files should match
this format exactly.

If applicable, files with intermediate results (.txt) are supplied for the
tests to aid in debugging. Please refer to the readme.txt file located in the
zip files below for detailed explanations.

Use of these vectors does not take the place of validation obtained
through the Cryptographic Algorithm Validation Program (CAVP).

186-2 DSA Test Vectors

186-2 RSA Test Vectors

RSA SigVer PKCS1.5 Vulnerability Test Vectors

RSA SigVer X9.31 Vulnerability Test Vectors

186-2 ECDSA Test Vectors

186-3 DSA Test Vectors

186-3 RSA Test Vectors

186-3 ECDSA Test Vectors

Other Information:

Elliptic curves recommended for Federal Government use are specified in
Appendix 6 of FIPS 186-2 with Change Notice 1 dated October 5,
2001. They are also listed separately: PDF and Word.

Back to
Top

Secure Hash Standard (SHS)

(SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256
algorithms)

The Secure Hash
Algorithms (SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and
SHA-512/256) are specified in FIPS 180-4 dated March 2012, Secure Hash Standard
(SHS).

Testing Requirements:

CST
labs can test for conformance to the SHA algorithms in FIPS 180-4. The
testing requirements for these algorithms can be found in the document titled The Secure Hash Algorithm Validation System (SHAVS).

Validation List:

NIST maintains the current SHA Validation List.

Test Vectors:

The following files provide an electronic version of the test vectors that
can be used to informally verify the correctness of the SHA algorithm
implementation using the SHAVS. These values are properly formatted in response
(.rsp) files. Vendor response files should match this format exactly.

If applicable, files with intermediate results (.txt) are supplied for the
tests to aid in debugging. Please refer to the readme.txt file located in the
zip files below for detailed explanations.

Use of these vectors does not take the place of validation obtained
through the Cryptographic Algorithm Validation Program (CAVP).

SHA Test Vectors for Hashing Bit-Oriented Messages

SHA Test Vectors for Hashing Byte-Oriented Messages

Back
to Top

Random Number Generators (RNG)

The algorithms for generating approved random numbers are referenced in FIPS 140-2 Annex C.

Testing Requirements:

CST
labs can test for conformance to the following RNG algorithms that are
referenced in FIPS 140-2 Annex C:

FIPS 186-2 with Change Notice 1 dated October 5, 2001
(Appendix 3.1 and 3.2)

ANSI X9.31 (Appendix A.2.4) - Using 2-Key Single
DES

NIST-Recommended Random Number Generator based on ANSI X9.31
Appendix A.2.4 using the 3-Key Triple DES and AES algorithms

ANSI X9.62 (Appendix A.4).
Copies of the ANSI X9.31
and ANSI X9.62 standards are available from X9, a standards committee accredited by the American National
Standards Institute (ANSI). NIST does NOT have copies of these standards
available for distribution.

The testing requirements for these algorithms can be found in the document
titled The Random Number Generator Validation System (RNGVS).

Validation List:

NIST maintains the current RNG Validation List.

Test Vectors:

RNG Test Vectors - These files provide an electronic version of the test
vectors that can be used to informally verify the correctness of an RNG
algorithm implementation using the RNGVS. However, use of these
vectors does not take the place of validation obtained through the Cryptographic
Algorithm Validation Program (CAVP).

RNG
Test Vectors
Back to Top

Deterministic Random Bit Generators (DRBG)

SP 800-90A Recommendation for Random Number Generation Using
Deterministic Random Bit Generators specifies mechanisms for the
generation of random bits using deterministic methods. There are four mechanisms
discussed in this Special Publication. These mechanisms are based on either hash
functions (Hash_DRBG, HMAC_DRBG), block cipher algorithms using Counter mode
(CTR_DRBG ) or number theoretic (Dual EC_DRBG) problems.

Testing Requirements:

CST labs can test for conformance to the DRBG algorithms in Special
Publication 800-90. The testing requirements for this algorithm can be found in
the document titled The DRBG Validation System (DRBGVS). Additional
testing note: Each of the mechanisms containing underlying algorithms
which must be validated as part of the DBRG validation. For HASH_DRBG, the SHA
algorithm(s) must be tested. For HMAC_DRBG, the HMAC algorithm must be tested.
For the block cipher algorithms using Counter mode CTR_DRBG, a NIST-Approved
symmetric key algorithm using Counter mode, must be validated as part of the
CMAC validation. Currently, NIST approves both the AES and TDES algorithms for
use with DRBG. For Dual EC_DRBG, the ECDSA Key Generation function and the SHA
algorithm must be tested. The ECDSA Key Generation function tests the point
multiplication function used in the Dual EC_DRBG.

Validation List:

NIST maintains the current DRBG Validation List.

Test Vectors:

DRBG Test Vectors - These files provide an electronic version of the test
vectors that can be used to informally verify the correctness of a DRBG
algorithm implementation using the DRBGVS. However, use of these vectors
does not take the place of validation obtained through the Cryptographic
Algorithm Validation Program (CAVP).

DRBG
Test Vectors DRBG Test Vectors In this zip file, there are 4 text files with
NIST SP 800-90 DRBG test vectors: HASH_DRBG.txt, HMAC_DRGB.txt,
CTR_DRBG.txt, and Dual_EC_DRBG.txt..
Back to Top

Key Management -Key Agreement Schemes and Key Confirmation (KAS)

SP 800-56A Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography (Revised March 2007)
specifies key establishment schemes based on standards developed by the
Accredited Standards Committee (ASC) X9, Inc.: ANS X9.42 (Agreement of Symmetric
Keys Using Discrete Logarithm Cryptography) and ANS X9.63 (Key Agreement and Key
Transport Using Elliptic Curve Cryptography).

Testing Requirements:

CST labs can test for conformance to the Key Agreement Schemes (KAS) and Key
Confirmation algorithms specified in Special Publication 800-56A. The testing
requirements for this algorithm can be found in the document titled The KAS Validation System (KASVS). Additional testing
note: The KAS validation process requires additional prerequisite
testing of the underlying DSA and/or ECDSA algorithm based on which type of
cryptography is supported and which underlying cryptographic functions are
supported, the supported SHA algorithm(s), supported MAC algorithm(s) (CCM,
CMAC, and/or HMAC), and the supported RNG and/or DRBG algorithm(s). (See CAVP
FAQ GEN.5 for more detailed information on prerequisites.)

Validation List:

NIST maintains the current KAS Validation List.

Test Vectors:

KAS Test Vectors - These files provide an electronic version of the test
vectors that can be used to informally verify the correctness of a key agreement
scheme and key confirmation algorithm implementation using the KASVS.
However, use of these vectors does not take the place of validation
obtained through the Cryptographic Algorithm Validation Program (CAVP).

KAS
Test Vectors See the KASVS document for an explanation of the files.
Back to Top

Message Authentication (MAC)

Block Cipher-based MAC Algorithm (CMAC)

The CMAC algorithm is specified in Special Publication 800-38B dated May 2005, Recommendation for
Block Cipher Modes of Operation: The CMAC Mode for Authentication. CMAC can be
considered a mode of operation of the block cipher because it is based on an
approved symmetric key block cipher, such as the Advanced Encryption Standard
(AES) algorithm currently specified in Federal Information Processing Standard
(FIPS) Pub. 197. CMAC is also an approved mode of the Triple Data Encryption
Algorithm (TDEA).

NOTE: Replacement examples have been provided to correct the examples located
in the back of SP800-38B. (Updated SP800-38B Examples).

Testing Requirements:

CST labs can test for conformance to the CMAC algorithm in Special
Publication 800-38B. The testing requirements for this algorithm can be found in
the document titled The CMAC Validation System (CMACVS). Additional
testing note: The CMAC validation process requires additional
prerequisite testing of the underlying NIST-Approved symmetric key algorithm
using any mode of operation used by the CMAC implementation that utilizes the
forward cipher function. Currently, NIST approves both the AES and TDES
algorithms for use with CMAC.

Validation List:

NIST maintains the current CMAC Validations. CMAC Validations are included on
the validation list of its approved symmetric key block cipher -- therefore it
is included on either the AES Validation List or the TDES Validation List.

Test Vectors:

CMAC Test Vectors - These files provide an electronic version of the test
vectors that can be used to informally verify the correctness of a CMAC
algorithm implementation using the CMACVS. However, use of these
vectors does not take the place of validation obtained through the Cryptographic
Algorithm Validation Program (CAVP).

CMAC
Test Vectors

Counter with Cipher Block Chaining-Message Authentication Code (CCM)

The Counter with Cipher Block Chaining-Message Authentication Code (CCM) is
specified in Special Publication 800-38C dated May, 2004, Counter with
Cipher Block Chaining-Message Authentication Code (CCM). CCM is based on an
approved symmetric key block cipher algorithm whose block size is 128 bits, such
as the Advanced Encryption Standard (AES) algorithm currently specified in
Federal Information Processing Standard (FIPS) Pub. 197 [2]; thus, CCM cannot be
used with the Triple Data Encryption Algorithm [3], whose block size is 64 bits.
Currently the only NIST-Approved 128 bit symmetric key algorithm is AES.

Testing Requirements:

CST labs can test for conformance to the CCM algorithm in Special Publication
800-38C. The testing requirements for this algorithm can be found in the
document titled The Counter with Cipher Block Chaining-Message Authentication Code
(CCM) Validation System (CCMVS). Additional testing note:
The CCM validation process requires additional prerequisite testing of the
underlying NIST-Approved 128 bit symmetric key algorithm using any mode of
operation used by the CCM implementation that utilizes the forward cipher
function. Currently, the only 128 bit symmetric key algorithm approved by NIST
is AES.

Validation List:

NIST maintains the current CCM Validations. CCM Validations are included on
the validation list of its approved symmetric key block cipher whose block size
is 128 bits-- therefore it is included on the AES Validation List. NIST maintains the original CCM Validation List. for historical purposes. The information
contained on the CCM Validation List has been duplicated in the AES Validation
List.

Test Vectors:

CCM Test Vectors - These files provide an electronic version of the test
vectors that can be used to informally verify the correctness of a CCM algorithm
implementation using the CCMVS. However, use of these vectors does
not take the place of validation obtained through the Cryptographic Algorithm
Validation Program (CAVP).

CCM
Test Vectors

Galois/Counter Mode (GCM) and GMAC

The Galois/Counter Mode (GCM) and GMAC is specified in Special Publication 800-38D dated November, 2007,
Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM)
and GMAC. GCM is based on an approved symmetric key block cipher algorithm whose
block size is 128 bits, such as the Advanced Encryption Standard (AES) algorithm
currently specified in Federal Information Processing Standard (FIPS) Pub. 197
[2]; thus, GCM cannot be used with the Triple Data Encryption Algorithm [3],
whose block size is 64 bits. Currently the only NIST-Approved 128 bit symmetric
key algorithm is AES.

Testing Requirements:

CST labs can test for conformance to the GCM and GMAC algorithms in Special
Publication 800-38D. The testing requirements for this algorithm can be found in
the document titled The Galois/Counter Mode (GCM) and GMAC Validation System
(GCMVS). Additional testing note: The GCM validation
process requires additional prerequisite testing of the underlying NIST-Approved
128 bit symmetric key algorithm using any mode of operation used by the GCM
implementation that utilizes the forward cipher function. Currently, the only
128 bit symmetric key algorithm approved by NIST is AES. If the IVs are
generated internally, the RNG or DRBG must also be validated.

Validation List:

NIST maintains the current GCM Validations. GCM Validations are included on
the validation list of its approved symmetric key block cipher whose block size
is 128 bits-- therefore it is included on the AES Validation List.

Test Vectors:

GCM Test Vectors - These files provide an electronic version of the test
vectors that can be used to informally verify the correctness of a GCM algorithm
implementation using the GCMVS. However, use of these vectors does
not take the place of validation obtained through the Cryptographic Algorithm
Validation Program (CAVP).

GCM Test Vectors

Keyed-Hash Message Authentication Code (HMAC)

The Keyed-Hash Message Authentication Code (HMAC) is specified in FIPS 198 dated March 6, 2002, Keyed-Hash Message
Authentication Code (HMAC). This algorithm utilizes the Secure Hash Algorithms
as an underlying primitive.

Testing Requirements:

CST labs can test for conformance to the HMAC algorithm in FIPS 198. The
testing requirements for these algorithms can be found in the document titled The Keyed-Hash Message Authentication Code (HMAC) Validation
System (HMACVS). Additional testing note: All underlying
SHA algorithm(s) supported by the HMAC implementation must be validated as part
of the HMAC validation.

Validation List:

NIST maintains the current HMAC Validation List.

Test Vectors:

HMAC Test Vectors - These files provide an electronic version of the test
vectors that can be used to informally verify the correctness of an HMAC
algorithm implementation using the HMACVS. However, use of these
vectors does not take the place of validation obtained through the Cryptographic
Algorithm Validation Program (CAVP).

HMAC
Test Vectors
Back to Top

SP 800-108 Key Derivation Using Pseudorandom Functions - Key-Based - (KBKDF)

SP 800-108 dated October 2009, Recommendation for Key
Derivation Using Pseudorandom Functions specifies techniques for the derivation
of additional keying material from a secret key, either established through a
key establishment scheme or shared through some other manner, using pseudorandom
functions.

Testing Requirements:

CST labs can test for conformance to the Key-based Key Derivation Functions
(KBKDF) specified in Special Publication 800-108. The testing requirements for
this algorithm can be found in the document titled The SP800-108 Key Derivation Function Validation System
(KBKDFVS)..

Additional testing note: The KBKDF validation process
requires additional prerequisite testing of the underlying CMAC and/or HMAC
algorithm based on which MAC algorithm is supported and, the underlying
algorithm used to generate the key derivation key (SP800-56A KAS, SP800-90A
DRBG, and/or RNG). (See CAVP FAQ GEN.5 for more detailed information on
prerequisites.)

Validation List:

NIST maintains the current SP800-108 KBKDF Validation List. .

Test Vectors:

KBKDF Test Vectors - These files provide an electronic version of the test
vectors that can be used to informally verify the correctness of Key Derivation
Functions (KDF) using Counter Mode, Feedback Mode, and/or Double-Pipeline
Iteration Mode via the validation testing described in the KBKDFVS.
However, use of these vectors does not take the place of validation
obtained through the Cryptographic Algorithm Validation Program
(CAVP).

Test Vectors for SP 800-108 KDFs See the KBKDFVS document for an explanation
of the files.

KDF in Counter Mode Test Vectors

KDF in Feedback Mode Test Vectors where no counter is
used

KDF in Feedback Mode Test Vectors where zero length IV is
allowed

KDF in Feedback Mode Test Vectors where zero length IV is not
allowed

KDF in Double-Pipeline Iteration Mode Test Vectors where no
counter is used

KDF in Double-Pipeline Iteration Mode Test Vectors where counter
is used

Algorithm Component Validation Testing

Beginning in 2011, the CAVP offers the validation of algorithm components.
There exists an increased need for the testing of individual components of
approved algorithms. Some examples of situations where algorithm component
testing will be required includes PIV Smartcard applications, where there are
processing limitations, and situations where parts of special publications can
be used with components outside the special publication. The components for
which we have validation testing are listed below.

SP 800-56A Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH)
Primitive Testing

The testing of only the SP800-56A Section 5.7.1.2 Elliptic Curve
Cryptography Cofactor Diffie-Hellman (ECC CDH) Primitive.

NIST SP 800-56A , Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography (Revised March
2007), Section 5.7.1.2.

Testing Requirements:

Validation testing for SP800-56A Section 5.7.1.2 ECC CDH Primitive component
testing is handled by the Cryptographic Algorithm Validation Program's (CAVP) CST labs.

ECC CDH Primitive tests are described in The Elliptic Curve Cryptography Cofactor Diffie_Hellman (ECC
CDH) Primitive Validation System (ECC_CDHVS).

Validation List:

NIST maintains the current Component Validation List. This CVL contains the validated
implementations of the ECC CDH Primitive.

Other Information:

ECC CDH Primitive Test Vectors - This file provides an
electronic version of the test vectors that can be used to informally verify
the correctness of the SP 800-56A Section 5.7.1.2 ECC CDH Primitive component
testing, using the validation tests described in The Elliptic Curve Cryptography Cofactor Diffie_Hellman (ECC
CDH) Primitive Validation System (ECC_CDHVS). However, use of
these vectors does not take the place of validation obtained through the
Cryptographic Algorithm Validation Program (CAVP).

SP 800-135 Revision 1 Recommendation for Existing Application-Specific Key
Derivation Functions

Validation testing for each individual key derivation function in NIST SP 800-135 (Revision 1) Recommendation for Existing
Application-Specific Key Derivation Functions December 2011.

Testing Requirements:

Validation testing for SP800-135 key derivation functions (KDF) component
testing is handled by the Cryptographic Algorithm Validation Program's (CAVP) CST labs.

SP800-135 validation tests are described in The SP800-135 Validation System).

Validation List:

NIST maintains the current Component Validation List. This CVL contains the validated
implementations of the KDFs described in SP800-135.

Other Information:

The following files provide an electronic version of the test vectors that
can be used to informally verify the correctness of the KDF algorithm
implementation using the ASKDFVS. These values are properly formatted in
response (.rsp) files. Vendor response files should match this format exactly.
If applicable, files with intermediate results (.txt) are supplied for the tests
to aid in debugging. Please refer to the readme.txt file located in the zip
files below for detailed explanations. However, use of these vectors
does not take the place of validation obtained through the Cryptographic
Algorithm Validation Program (CAVP).

IKEv1 KDF Test Vectors

IKEv2 KDF Test Vectors

TLS KDF Test Vectors

ANS X9.63-2001 KDF Test Vectors

SSH KDF Test Vectors

SRTP KDF Test Vectors

SNMP KDF Test Vectors

TPM KDF Test Vectors

FIPS 186-3 ECDSA Signature Generation Component Testing

This component test assumes the IUT requires hash sized messages as input to
the Signature Generation function. This validation test was designed for
applications like the PIV card.

Testing Requirements:

Validation testing for FIPS 186-3 ECDSA Signature Generation component
testing is handled by the Cryptographic Algorithm Validation Program's (CAVP) CST labs.

FIPS 186-3 ECDSA Signature Generation component testing is the same as
ECDSA Signature Generation tests except the length of the input message is the
length of the hash value supported. Please see the Signature Generation tests
described in The Elliptic Curve Digital Signature Algorithm Validation System
(ECDSA2VS).

Validation List:

NIST maintains the current Component Validation List. This CVL contains the validated
implementations of the FIPS 186-3 ECDSA Signature Generation Component Primitive
Testing.

Other Information:

FIPS 186-3 ECDSA Signature Generation Component Test Vectors
- This file provides an electronic version of the test vectors that can be
used to informally verify the correctness of the FIPS 186-3 Signature
Generation component testing, using the validation tests described in The Elliptic Curve Digital Signature Algorithm Validation System
(ECDSA2VS). However, use of these vectors does not take the
place of validation obtained through the Cryptographic Algorithm Validation
Program (CAVP).

FIPS 186-3 RSA PKCS1-v1_5 RSASP1 Signature Primitive Component Testing

This component test tests the RSASP1 function as described in PKCS#1 v2.1:RSA
Cryptography Standard, June 14,2002. This validation test was designed for
applications like the PIV card.

Testing Requirements:

Validation testing for FIPS 186-3 RSA PKCS1-v1_5 RSASP1 Signature Primitive
Component testing is handled by the Cryptographic Algorithm Validation Program's
(CAVP) CST labs.

FIPS 186-3 RSA PKCS1-v1_5 RSASP1 Signature Primitive Component testing
inputs messages in the encoded message EM format for PKCS1-v1_5. It returns
the signature s.

Validation List:

NIST maintains the current Component Validation List. This CVL contains the validated
implementations of the FIPS 186-3 RSA PKCS1-v1_5 RSASP1 Signature Primitive
Component Testing.

Other Information:

FIPS 186-3 RSA PKCS1-v1_5 RSASP1 Signature Primitive Component
Test Vectors - This file provides an electronic version of the test
vectors that can be used to informally verify the correctness of the FIPS
186-3 Signature Primitive component testing, using the validation tests
described in The RSASP1 Signature Primitive Validation System (RSASP1VS).
However, use of these vectors does not take the place of
validation obtained through the Cryptographic Algorithm Validation Program
(CAVP).

FIPS 186-3 RSA PKCS1-vPSS RSASP1 Signature Primitive Component Testing

This component test tests the RSASP1 function as described in PKCS#1 v2.1:RSA
Cryptography Standard, June 14,2002. This validation test was designed for
applications like the PIV card.

Testing Requirements:

Validation testing for FIPS 186-3 RSA PKCS1-vPSS RSASP1 Signature Primitive
Component testing is handled by the Cryptographic Algorithm Validation Program's
(CAVP) CST labs.

FIPS 186-3 RSA PKCS1-v1_5 RSASP1 Signature Primitive Component testing
inputs messages in the encoded message EM format for PKCS1-vPSS. It returns
the signature s verifying the correct result.

Validation List:

NIST maintains the current Component Validation List. This CVL contains the validated
implementations of the FIPS 186-3 RSA PKCS1-vPSS RSASP1 Signature Primitive
Component Testing.

Other Information:

FIPS 186-3 RSA PKCS1-PSS RSASP1 Signature Primitive Component
Test Vectors - This file provides an electronic version of the test
vectors that can be used to informally verify the correctness of the FIPS
186-3 Signature Primitive component testing, using the validation tests
described in The RSASP1 Signature Primitive Validation System (RSASP1VS).
However, use of these vectors does not take the place of
validation obtained through the Cryptographic Algorithm Validation Program
(CAVP).

Back to Top

Retired Validation Testing

Data Encryption Standard (DES)

FIPS 46-3, Data Encryption Standard (DES), was withdrawn May 19, 2005 because
the cryptographic algorithm no longer provided the security that is needed to
protect Federal government information. DES is no longer an Approved algorithm.
The DES Algorithm Validation Webpage is still accessible via the Validations
List webpage, for historical purposes only.

Data (Message) Authentication Code (MAC) and Key Management Using ANSI
X9.17

The automated conformance tests for FIPS 113 and 171 are no longer
operational. Currently, if a FIPS 140-1 or FIPS 140-2 cryptographic module
implements either of these two standards, the CST testing
laboratories perform some testing that these FIPS requirements are
implemented correctly in the cryptographic module.

Message Authentication Code (MAC), FIPS 113

The MAC Validation System (MVS) tested for compliance with FIPS 113, Computer Data Authentication. A list of validated products is maintained by the Security Technology
Group.

Key Management Using ANSI X9.17, FIPS 171

The Key Management Validation System (KMVS) tested for compliance with FIPS
171, Key Management Using ANSI X9.17. A list of validated
products is maintained by the Security Technology
Group.

CSRC Webmaster, Disclaimer Notice & Privacy
Policy
NIST is an Agency
of the U.S.
Department of Commerce

Last updated: January 8, 2013
Page created: January 28, 1996