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.
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.
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.
Validation testing for AES, Triple-DES, and Skipjack algorithms are handled by the Cryptographic Algorithm Validation Program's (CAVP) CST labs.
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.
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).
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.
Validation testing for XTS-AES mode of operation algorithm is handled by the Cryptographic Algorithm Validation Program's (CAVP) CST labs.
NIST maintains the current XTS-AES Validations. XTS-AES validations are included on the AES Validation List.
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:
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:
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.
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.
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:
New items in the DSS include:
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.
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:
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.
NIST maintains the current DSA, ECDSA, and RSA Validation Lists.
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).
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.
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).
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).
NIST maintains the current SHA Validation List.
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).
The algorithms for generating approved random numbers are referenced in FIPS 140-2 Annex C.
CST labs can test for conformance to the following RNG algorithms that are referenced in FIPS 140-2 Annex C:
The testing requirements for these algorithms can be found in the document titled The Random Number Generator Validation System (RNGVS).
NIST maintains the current RNG Validation List.
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).
Back to TopSP 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.
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.
NIST maintains the current DRBG Validation List.
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 TopSP 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).
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.)
NIST maintains the current KAS Validation List.
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 TopThe 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).
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.
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.
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).
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.
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.
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.
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).
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.
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.
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.
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).
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.
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.
NIST maintains the current HMAC Validation List.
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).
Back to TopSP 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.
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.)
NIST maintains the current SP800-108 KBKDF Validation List. .
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
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.
The testing of only the SP800-56A Section 5.7.1.2 Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH) Primitive.
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.
NIST maintains the current Component Validation List. This CVL contains the validated implementations of the ECC CDH Primitive.
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.
Validation testing for SP800-135 key derivation functions (KDF) component testing is handled by the Cryptographic Algorithm Validation Program's (CAVP) CST labs.
NIST maintains the current Component Validation List. This CVL contains the validated implementations of the KDFs described in SP800-135.
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).
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.
Validation testing for FIPS 186-3 ECDSA Signature Generation component testing is handled by the Cryptographic Algorithm Validation Program's (CAVP) CST labs.
NIST maintains the current Component Validation List. This CVL contains the validated implementations of the FIPS 186-3 ECDSA Signature Generation Component Primitive 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.