NIST Logo and ITL Banner Link to the NIST Homepage Link to the ITL Homepage Link to the NIST Homepage
Search CSRC:

Announcements

[09-30-14] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS17.3). The following modifications have been made:

  1. One of the AAD length fields was not being read correctly in the 'Verify' routine.
  2. When both the Section 8.2.1 and Section 8.2.2 methods for generating the IV internally were checked, the cover letter only displayed one of them. It now displays both.
  3. GCM screen – Initialization Vector section: Corrected sentence on screen to reflect the valid minimum length to 8. (Valid lengths: 8 bits to 1024 bits)
  4. Key Wrap screen – AES Key Wrap (KW) Tested Plaintext Lengths section: Added clarification that the minimum value for an odd multiple of 64 is 64*3=192. (value >= 192)
  5. Key Wrap screen – TDES Key Wrap (TKW) Tested Plaintext Lengths section:  Added clarification that the minimum value for an odd multiple of 32 is 32*3=96. (value >= 96)

The transition period ends December 30, 2014.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component and/or SP 800-38F Key Wrapping, the CST lab must use the CAVS17.3 to validate the IUT.
  2. For any algorithm validation request where a lab has used CAVS 17.2 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through December 30, 2014. 
  3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 17.3.

The CAVP will also review special conditions on a case-by-case basis.

[08-21-14] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS17.2). The following modifications have been made:

  1. GCM test vector files – modified header to remove single quotes from around product folder name. This was causing the verification of the files to fail.

The transition period ends November 14, 2014.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component and/or SP 800-38F Key Wrapping, the CST lab must use the CAVS17.2 to validate the IUT.
  2. For any algorithm validation request where a lab has used CAVS 17.1 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through November 14, 2014.  (Note: CAVS 17.1 was released on August 14, 2014. Since the change to CAVS 17.2 is minor and since CAVS 17.1 has only been available for a week, the transition period for CAVS 17.1 will end on the same date as CAVS17.0. Therefore, NIST will accept validations using CAVS 17.1 up through November 14, 2014, as stated above.)
  3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 17.2.

The CAVP will also review special conditions on a case-by-case basis.

[08-14-14] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS17.1). The following modifications have been made:

  1. Key Wrap (NIST SP 800-38F) a. CAVS provides five fields for tested plaintext lengths. Previously, all five needed valid, nonzero values in order for the tests to run. However, conforming NIST SP 800-38F implementations do not need to set all five input lengths, only those that are supported b. indicate unused lengths by entering a 0 in the field
  2. DRBG - for CTR_DRBG using derivation function (df). The derivation function only accepts bit strings that are a multiple of 8 bits long. Therefore, CAVS now restricts: * additional input length to multiple of 8 bits * sum of entropy input, nonce and personalization string lengths to 8 bits
  3. SP800-108 – Was not handling zero values in the L fields correctly. This has been corrected by ignoring the zero values.
  4. 186-2 RSA Signature Generation for PKCS-PSS mod size 2048, 3072 and 4096 (used for CMVP module revalidations requiring FIPS 186-2 RSA implementations to be tested) – CAVS will now allow salt lengths that don’t adhere to the 186-4 specifications as was allowed before 186-4 changed the specifications. THIS CAN ONLY BE USED FOR USE IN CMVP REVALIDATIONS.
  5. Corrected RSA2’s REVALONLY section in inf file to = True only when something for FIPS186-2 is selected.
  6. TDES – Changed the message displayed at the completion of verify TDES to indicate if the test passed or failed.
  7. GCM test vector files – added header that mentions product folder name.
  8. KDF-800-135 – Corrected the message displayed at the completion of Verify to indicate if it passed or failed.
  9. HMAC screens – added information to identify that lengths are represented in bytes.

The transition period ends November 14, 2014.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component and/or SP 800-38F Key Wrapping, the CST lab must use the CAVS17.1 to validate the IUT.
  2. For any algorithm validation request where a lab has used CAVS 17.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through November 14, 2014. 
  3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 17.1.

The CAVP will also review special conditions on a case-by-case basis.

[07-10-14] -- The format of the FIPS 186-4 RSA Key Generation test was redesigned in March 2014. (For reference, the 2 formats are referred to as "the old format" and "the new format".) Beginning July 2014, the vendor may choose either format to test their 186-4 RSA Key Generation. Both formats are equivalent. The "old format" of the test provided some values to the IUT and the IUT used these values to calculate the required answers. The "new format" requires the IUT to supply all the values used for testing.

Both the old format of the FIPS 186-4 RSA Key Generation test and the new format of the FIPS 186-4 RSA Key Generation test provide the same level of testing for the FIPS 186-4 RSA Key Generation function. The CAVP has decided that the vendor can select either test for testing implementations of FIPS 186-4 RSA Key Generation.

The CAVP is allowing this because we recognize that the redesign of the Key Generation test may impact a vendor's design of their implementation. A vendor who has either already started the design of their implementation or who has tested their implementation once using the old formatted test and now wishes to test another version of the same implementation, may need to make modifications to their design in order to be able to run the new format of the validation test. This may require a non-trivial amount of effort and time leading to severe delays in the validation process. If the tests are equivalent, it is unnecessary to cause this issue.

[06-19-14] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS17.0). The following modifications have been made:

  1. Added validation testing for SP800-38F Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping.
  2. Comment line of the RSA SigGen files contained “[mod = 4096]” string.  The square brackets are used to indicate a section in the file.  Since the square brackets used in the comment line are not the beginning of a file section, an error occurred.  Removed the square brackets from the comment line.
  3. The RSA component check boxes were not being checked when the screen was called up after exiting CAVS and going back in.  Even though the information was correct in the inf file.  Corrected the program to populate the check boxes when restarting CAVS.
  4. For SP800-56A Revision 2: Changed the minimum length restrictions for MACKey MAC Len for all MACs as specified in 5.2.1.
  5. RSA Key Gen Summary file correctly indicated that each individual section of the test passed but erroneously indicated the summary of all tests failed.  This bug was introduced when adding mod 4096. It has been corrected.
  6. ECDSA2 Summary file was indicating KeyGen failed but it passed 30 out of 30 for every curve.  This bug was introduced when adding FIPS186-2 Key Pair Generation option. Updated expected iterations to correct this error.
  7. Changed format of inf file RSA2 to have separate section for all of REVALONLY tests instead of mixing this in each section.  Also put label REVALONLY_ at the beginning of each line. (Request for automation)
  8. Added “REVALONLY_” label to front of ECDSA2 KeyPair_FIPS186_2 in inf file. (Request for automation)
  9. Removed SigGen message “Note 186-2 SigGen Mod4096 Only for use in CMVP SUB report submission” from SigVer screens for X9.31 and PKCS1.5.  This screen is shared by these two functions and needed to be block from the SigVer screens.
  10. RSADP – in inf file changed section to only have information for 2048 mod size.
  11. GCM testing – increased maximum supported plaintext and AAD lengths from 1024 bits to 65536 bits.

The transition period ends Sept 19, 2014.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component and/or SP 800-38F Key Wrapping, the CST lab must use the CAVS17.0 to validate the IUT.
  2. For any algorithm validation request where a lab has used CAVS 16.3 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through September 19, 2014. 
  3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 17.0.

The CAVP will also review special conditions on a case-by-case basis.

[05-07-14] -- Updated CAVP Frequently Asked Questions (FAQ) document.


[04-23-14] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS16.3). The following modifications have been made:

  1. Added additional error checking to RSA Key Gen to assure the input values supplied by the IUT are valid values (ex, odd integers if they are supposed to be, valid lengths based on Table B.1, etc.). Error messages will be printed to the logfile to indicate these errors.
  2. Fixed bug in GCMTab.cpp.
  3. In CAVS 16.2, when the 4096 column was added to the RSA SigGen screens, it also was being displayed in the SigVer screens. It shouldn’t be on the SigVer screens. Removed 4096 column in SigVer9.31 and SigVerPKCS1.5 screens.
  4. For RSA Key Gen B3.3, added check box to indicate if supports fixed or random values for public key e.

The transition period ends July 23, 2014.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component and/or the RSADP component, the CST lab must use the CAVS16.3 to validate the IUT.
  2. For any algorithm validation request where a lab has used CAVS 16.2 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through July 23, 2014.
  3. 3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 16.3.

The CAVP will also review special conditions on a case-by-case basis.

[04-01-14] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS16.2). The following additions, modifications and updates have been made:

  1. ECDSA2 Summary File - Correction for error when Sig Gen not selected it didn't say "Not Configured".
  2. Change labels in inf file for Legacy_FIPS186-2 entries: Change dash to underscore.
  3. Added 186-2 RSA Signature Generation for 4096 to Sig Gen tabs to allow for use with CMVP 1SUB, 2SUB and 4SUB report submissions.
  4. Added 186-2 RSA Key Generation to Key Gen tab to allow for use with CMVP 1SUB, 2SUB and 4SUB report submissions.
  5. Removed a file name that was used for KAS debugging purposes. The file is named configvalues.txt and was being written to directory d . If the machine running CAVS didn’t have a drive d, an error was displayed. If the machine running CAVS did have a drive d, it created this file. Labs should look on their d drive (it they have one) and remove this file.
  6. Removed three file names that were used for debugging purposes. They were written to d directory and can be deleted by labs if found on their machines. The file names are B35.txt (for RSA Key Gen testing), ecdsa2_verify.txt (for ECDSA testing), and ecdsa2_verify_component.txt (for ECDSA component testing ).
  7. Fixed bug in CAVS Screen Status for DRBG. Before this fix, the status screen for DRBG would show that both Hash_DRBG and HMAC_DRBG were tested for a particular SHA function whenever either one (Hash_DRBG or HMAC_DRBG) was actually tested. Please note that the ‘Display Status’ feature has not been actively maintained for several versions and should not be used as an accurate indication of testing status.
  8. Fixed bug in AES_GCM. A 0 (zero) in any of the Plaintext and AAD bit length fields is supposed to be interpreted as ‘not supported’; however, CAVS was interpreting them as a supported zero bit length. Zero-length Plaintext and AAD support is indicated by checking the checkbox labelled ‘Check if supports 0 length Plaintext (GMAC)’ or ‘Check if supports 0 length AAD”.

The transition period ends July 1, 2014.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component and/or the RSADP component, the CST lab must use the CAVS16.2 to validate the IUT.
  2. For any algorithm validation request where a lab has used CAVS 16.1 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through July 1, 2014.
  3. 3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 16.2.

The CAVP will also review special conditions on a case-by-case basis.

[03-18-14] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS16.1). The following additions, modifications and updates have been made:

  1. Fixed bugs in ECDSA2 Signature Generation Component test.
  2. Removed note on RNG screen restricting its use because on 1/7/14, IG G.14 was updated removing the following text: “In the case of the deprecated RNGs, new algorithm or module validation submissions will only be accepted for validation by the CAVP or CMVP, respectively, through the end of 2013. However, modules submitted for revalidation under IG G.8, scenario 1 through 4 containing deprecated RNGs will be accepted for revalidation by the CMVP until their use is disallowed on Dec 31, 2105.”
  3. Changed references of 186-3 to 186-4 in the RSANotes and RSAPrerequisite screens.
  4. Started adding the changes for SP800-56A Revision 2. In FFC screens only, changed the minimum lengths allowed. (See Section 5.2.1 of SP 800-56A Revision 2)
  5. Added labels to values displayed during KASECC verification for assistance when debugging IUT.
  6. Fixed bugs in RSA Legacy Signature Verification: a. Names of files should be SigVer931_186-2.xxx instead of SigVerRSA_186-2.xxx b. Summary file correction
  7. Changed RSA2 Key Generation tests. The IUT now supplies all the values for the Key Generation tests. The Fixed or Random public key parameter is no longer asked for or recorded on webpage because the IUT will supply the public keys that it can support.
  8. Modified RSASP1 validation test to only test the RSASP1 component. Originally it was testing more than the RSASP1 component.
  9. Added FIPS 186-2 Key Gen testing to ECDSA2 Key Pair tab for revalidation only.
  10. Removed 1536 bit length from list of Diffie-Hellman shared secret lengths for testing IKE v1 and IKE v2 KDFs.
  11. For DSA legacy domain parameter verification, CAVS generated PQGVer1862.fax in the sample file directory. The extension (.fax) was incorrect. Changed extension to .sam.

The transition period ends June 18, 2014.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component and/or the RSADP component, the CST lab must use the CAVS16.1 to validate the IUT.
  2. For any algorithm validation request where a lab has used CAVS 16.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through June 18, 2014.
  3. 3. If there are any validation requests where a lab has used a version of CAVS that has not expired (it's transition period is over) to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 16.1.

The CAVP will also review special conditions on a case-by-case basis.

[12-12-13] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS16.0). contains changes to the testable functions in some of the approved cryptographic algorithms to reflect the transition to the use of stronger cryptographic keys and more robust algorithms (as recommended in NIST SP800-131A Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths) effective January 1, 2014. The following changes have been made :

  1. DSA (Refers to FIPS 186-2) – Removed DSA tab. PQG Generation, Key Pair Generation, and Signature Generation are disallowed after 2013 because IG G.15 states “After December 31, 2013, implementations of domain parameter generation, key pair generation and digital signature generation as specified in FIPS 186-2 will not be validated by the CAVP or CMVP.” PQG Verification and Signature Verification are still allowed for legacy use. The testing of these 186-2 functions has been moved to the DSA2 tab which refers to FIPS 186-4. (NOTE: FIPS 186-4 DSA can still be validated for all functions (See DSA2 Tab).)
  2. RNG –IG G.15 states “ In the case of the deprecated RNGs, new algorithm or module validation submissions will only be accepted for validation by the CAVP or CMVP, respectively, through the end of 2013 . “ “However, modules submitted for revalidation under IG G.8, scenarios 1 through 4 containing deprecated RNGs will be accepted for revalidation by the CMVP until their use is disallowed on December 31, 2015 (see SP 800-131A).” In the case of revalidations, RNG validation may need to be performed. Therefore, RNG validation testing will remain in the CAVS tool but will only be allowed to validate RNG implementations in modules submitted for revalidation.
  3. DSA2 (Refers to 186-4) – The following changes have been made: a. Because modulus sizes less than or equal to 80 bits of security are disallowed and SHA1 is disallowed for Digital Signature Generation after 2013: i. PQG Gen – Removed “L=1024 N=160” column ii. Key Pair – Removed “L=1024 N=160” column iii. Signature Generation 1. Removed “L=1024 N=160” column 2. Removed SHA1 from all modulus columns b. The PQG Verification selection under the DSA2 tab has been modified to add a checkbox to test FIPS186-2 PQG Verification as specified in FIPS 186-4 Annex A.1.1.1 Validation of the Probable Primes p and q that were Generated Using SHA-1 as Specified in Prior Versions of this Standard. c. A note has been added to the Signature Verification selection under the DSA2 tab explaining that Signature Verification as specified in FIPS 186-2 and FIPS 186-4 is the same and therefore the same screen can be used to test either version. Therefore, there is no distinction between the two when testing Signature Verification.
  4. ECDSA2 (Refers to 186-4) - The following changes have been made: a. Because modulus sizes less than or equal to 80 bits of security are disallowed and SHA1 is disallowed for Digital Signature Generation after 2013: i. Key Pair – Removed P192 K163 B163 ii. Signature Generation 1. Removed the complete columns for P192 K163 and B163 2. Removed SHA1 from all curve columns b. Add documentation explaining PKV and Signature Verification for both 186-2 and 186-4 are the same. Therefore, there is no distinction between the two versions when testing these functions.
  5. RSA (Refers to FIPS 186-2) - Removed RSA tab. PQG Generation, Key Pair Generation, and Signature Generation are disallowed after 2013 because IG G.15 states “After December 31, 2013, implementations of domain parameter generation, key pair generation and digital signature generation as specified in FIPS 186-2 will not be validated by the CAVP or CMVP. “ Signature Verification is still allowed for legacy use. The 186-2 RSA Validation Tests have been moved under the RSA2 tab. They can be accessed by checking the 186-2 Legacy Tests tab under the RSA2 tab. (NOTE: FIPS 186-4 RSA can still be validated (See RSA2 Tab).)
  6. RSA2 (Refers to 186-4) – The following changes have been made: a. Because anything less than or equal to 80 bits of security is disallowed and SHA1 is disallowed for Digital Signature Generation after 2013: i. GenKey9.31 – Removed 1024 column only in B.3.4 (Provable Primes), B.3.5 (Provable and Probable Primes) and B.3.6 (Probable Primes), but kept SHA1. (1024 bit RSAs keys are not used for any other purpose but Signature Generation. Therefore they are removed. FIPS PUB 186-4 Section 4 states that SHA1 can be used for key generation because output length of 160 is bigger than 128 and 112 associated security string lengths of 2048 and 3072 bit moduli.) ii. Signature Generation 9.31, PKCS1.5 and PKCS PSS 1. Removed 1024 column 2. Removed SHA1 from modulus sizes 2048 and 3072 columns iii. RSA Component Test – Removed PKCS 1.5 SHA1 because SHA1 was removed from Mod 2048 b. Added new tab called 186-2 Legacy Tests. By selecting this tab, the FIPS 186-2 Signature Verification for 9.31, PKCS1.5 and PSS can be accessed.
  7. ECDSA (Refers to FIPS 186-2) - – Removed ECDSA tab. PQG Generation, Key Pair Generation, and Signature Generation are disallowed after 2013 because IG G.15 states “After December 31, 2013, implementations of domain parameter generation, key pair generation and digital signature generation as specified in FIPS 186-2 will not be validated by the CAVP or CMVP. “ PKV and Signature Verifications are still allowed for legacy use. The testing of these 186-2 functions has been moved to the ECDSA2 tab. (NOTE: FIPS 186-4 ECDSA can still be validated (See ECDSA2 Tab).)
  8. KASFFC – Removed FA parameter set because 80 bits security disallowed after 2013.
  9. KASECC – Because anything less than or equal to 80 bits of security is disallowed after 2013: a. Removed EA parameter set b. ECCCDH Component test (Sec 5.7.1.2) – Removed P192 K163 and B163.
  10. KDF 800-135 - – Because anything less than or equal to 80 bits of security is disallowed after 2013: a. IKE v1 – Removed 185, 192, 1024 from the 3 columns in the Diffie-Hellman Shared Secret section b. IKE v2 – Removed 185, 192, 1024 from the 3 columns in the Diffie-Hellman Shared Secret section c. ANS X9.63 – Removed 163 and 192 in both min and max fields d. SSH – Changed the Diffie-Hellman Shared Secret Lengths default value to 2048.
  11. RSADP Component (from SP800-56B) – Removed 1024. Because only allow 2048 now, modified screen so only need to press RSADP Generate or RSADP Verify.
  12. A minor bug was fixed in SP 800-135 to the shared secret length for IKEv1 and IKEv2.

The transition period ends March 12, 2014.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component and/or the RSADP component, the CST lab must use the CAVS 16.0 to validate the IUT.
  2. 2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 16.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations of acceptable algorithms and key lengths using this tool up through March 12, 2014. If an IUT validated with CAVS 15.2 contains key lengths, hash sizes, or algorithms that are disallowed as of December 31, 2013, these disallowed features will not be accepted.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 16.0 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 16.0.

The CAVP will also review special conditions on a case-by-case basis.

[11-13-13] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS15.2). The following additions, modifications and updates have been made to CAVS Version 15.1:

  1. Corrected message displayed for RSA2 Key Generation verification.  It was erroneously displaying success on the screen when the summary and log files were indicating a failure.
  2. Changes to format in RSADP files -Changed upper case K to lower case k in sample file
  3. Corrections to RSA2 testing introduced when truncated SHAs were added.  Error was in using SHA1. 
  4. Corrections to DRBG edit length dialog.
  5. Removed response file creation in SP800-108.  This was here for generating example files for website.

The transition period ends February 13, 2014.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, SHA 512/224, SHA 512/256, HMAC with SHA 512/224, HMAC with SHA 512/256, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component and/or the RSADP component, the CST lab must use the CAVS 15.2 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 15.2 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through February 13, 2014.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 15.2 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 15.2.

The CAVP will also review special conditions on a case-by-case basis.

[09-18-13] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS15.1). CAVS 15.1 contains all the additions and changes made to CAVS 15.0 plus some additional modifications and corrections. DO NOT USE CAVS VERSION 15.0. Instead, transition from CAVS Version 14.4 to CAVS Version 15.1. The following additions, modifications and updates have been made since CAVS Version 14.4:

  1. - Added FIPS 180-4 SHA-512/224 and SHA-512/256 support to FIPS 186-4 DSA (i.e., DSA2), ECDSA (i.e., ECDSA2), and RSA (i.e., RSA2).
  2. - Added SP800-56B RSADP component testing.
  3. - Added prerequisite to ECDSA Signature Generation component. Requires prerequisite of DRBG or RNG because uses secret random number.
  4. - For the NIST SP 800-135 IKEv1 and IKEv2 KDFs, the three fixed well-known group options (Groups 2, 4 and 14) are replaced by three drop-down lists of all valid shared secret lengths (groups), thus increasing the number of groups supported by testing.
  5. - For the NIST SP 800-135 SSH KDF, testing with the TDES-CBC cipher is now optional instead of required. The user shall select all supported block ciphers out of the set of TDES CBC, AES-128 CBC, AES-192 CBC and AES-256 CBC.
  6. - Fixed bug in NIST SP 800-135 SSH KDF tests. CAVS generated shared secret (i.e., K) values that were not valid because they had an unnecessary leading zero-valued byte.
  7. - For NIST SP 800-38E XTS-AES, CAVS now allows testing with the tweak value input in both supported formats, the 128-bit hexadecimal string and the Data Unit Sequence number. Earlier versions of CAVS only tested for one format or the other.
  8. - Fixed parsing bug in HMAC verify routine.
  9. - AES Summary file corrected for AES Ctr mode information.
  10. - Fixed bug in "Edit Input Lengths..." window for Hash_DRBG and HMAC_DRBG.
  11. - Modifications to inf file (For internal use):
    1. GCM –make “Selected=” first line in GCM section (this will make it consistent with other sections)
    2. 135-Change name of “800135Selected” to “Selected”
    3. Have an empty line before the DES section – or remove the DES section.
    4. For each component, make it have its own section In the inf file for automation purposes (separate section for ECDSA SigGenComponent, RSASP1 component, RSADP component, etc.)
    5. Corrected label in SP800-135 log file
  12. -Corrected truncated screen for SP800-135 IKEv2.

The transition period ends December 18, 2013.

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, SHA 512/224, SHA 512/256, HMAC with SHA 512/224, HMAC with SHA 512/256, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component and/or the RSADP component, the CST lab must use the CAVS 15.1 to validate the IUT.
  2. For any algorithm validation request where a lab has used CAVS Version 15.0 to create files, please regenerate everything using CAVS 15.1.
  3. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 15.1 (excluding CAVS 15.0) to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through December 18, 2013.
  4. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 15.1 (excluding CAVS 15.0) to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 15.1.

The CAVP will also review special conditions on a case-by-case basis.

[09-17-13] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS15.0). The following additions, modifications and updates have been made to CAVS Version 15.0:

  1. - Added FIPS 180-4 SHA-512/224 and SHA-512/256 support to FIPS 186-4 DSA (i.e., DSA2), ECDSA (i.e., ECDSA2), and RSA (i.e., RSA2).
  2. - Added SP800-56B RSADP component testing.
  3. - Added prerequisite to ECDSA Signature Generation component. Requires prerequisite of DRBG or RNG because uses secret random number.
  4. - For the NIST SP 800-135 IKEv1 and IKEv2 KDFs, the three fixed well-known group options (Groups 2, 4 and 14) are replaced by three drop-down lists of all valid shared secret lengths (groups), thus increasing the number of groups supported by testing.
  5. - For the NIST SP 800-135 SSH KDF, testing with the TDES-CBC cipher is now optional instead of required. The user shall select all supported block ciphers out of the set of TDES CBC, AES-128 CBC, AES-192 CBC and AES-256 CBC.
  6. - Fixed bug in NIST SP 800-135 SSH KDF tests. CAVS generated shared secret (i.e., K) values that were not valid because they had an unnecessary leading zero-valued byte.
  7. - For NIST SP 800-38E XTS-AES, CAVS now allows testing with the tweak value input in both supported formats, the 128-bit hexadecimal string and the Data Unit Sequence number. Earlier versions of CAVS only tested for one format or the other.
  8. - Fixed parsing bug in HMAC verify routine.
  9. - AES Summary file corrected for AES Ctr mode information.
  10. - Fixed bug in "Edit Input Lengths..." window for Hash_DRBG and HMAC_DRBG.
  11. - Modifications to inf file (For internal use):
    1. GCM –make “Selected=” first line in GCM section (this will make it consistent with other sections)
    2. 135-Change name of “800135Selected” to “Selected”
    3. Have an empty line before the DES section – or remove the DES section.
    4. For each component, make it have its own section In the inf file for automation purposes (separate section for ECDSA SigGenComponent, RSASP1 component, RSADP component, etc.)
    5. Remove dash, slash and spaces from truncated hash variable names (and other variables)

The transition period ends December 17, 2013.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, SHA 512/224, SHA 512/256, HMAC with SHA 512/224, HMAC with SHA 512/256, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component and/or the RSADP component, the CST lab must use the CAVS 15.0 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 15.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through December 17, 2013.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 15.0 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 15.0.

The CAVP will also review special conditions on a case-by-case basis.

[09-05-13] - On July 19,2013, NIST announced the approval of Federal Information Processing Standard (FIPS) 186-4, the Digital Signature Standard.  All of the changes between FIPS 186-3 and FIPS186-4 had already been incorporated into the CAVP testing tool; the testing of FIPS186-3 implementations is identical to the testing of FIPS 186-4 implementations. There is no need for a transition period in which both FIPS 186-3 and FIPS 186-4 validation would be performed. Previous CAVP validations for FIPS 186-3 will be considered as equivalent to those for FIPS 186-4. Vendors should start using FIPS 186-4 immediately.

[04-26-13] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS14.4). This version of the CAVS tool addresses minor updates:

  1. - For SP800-108 KDF in Counter Mode, added the ability to test implementations that put the counter in the middle of the input data. This is allowed by SP800-108.
  2. - Minor correction in file used by tool - doesn't affect end users: In function WriteInfRSA2, changed reference to rsa2selected instead of rsaselected.

The transition period ends July 23, 2013.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, SHA 512/224, SHA 512/256, HMAC with SHA 512/224, HMAC with SHA 512/256, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, and/or the ECDSA2 Signature Generation Component, the CST lab must use the CAVS 14.4 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 14.4 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through July 23, 2013.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 14.4 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 14.4.

The CAVP will also review special conditions on a case-by-case basis.


[02-21-13] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS14.3). This version of the CAVS tool addresses minor updates:

  1. - Corrected RSA summary file to correctly handle values from KeyGen 3.3 fixed key.
  2. - Added FIPS 180-4 truncated SHA functions SHA-512/224 and SHA-512/256 to the Hash_DRBG, HMAC_DRBG, and Dual_EC_DRBG tests.
  3. - Changed order that DRBG mechanism functions are called in tests when Prediction Resistance = False Old order: 1. Instantiate DRBG 2. Generate Random Bits (do not print) 3. Reseed 4. Generate Random Bits (print) 5. Uninstantiate New Order: 1. Instantiate DRBG 2. Reseed 3. Generate Random Bits (do not print) 4. Generate Random Bits (print) 5. Uninstantiate The order is unchanged for Prediction Resistance = True.

The transition period ends May 21, 2013.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, SHA 512/224, SHA 512/256, HMAC with SHA 512/224, HMAC with SHA 512/256, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, and/or the ECDSA2 Signature Generation Component, the CST lab must use the CAVS 14.3 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 14.3 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through May 21, 2013.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 14.3 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 14.3.

The CAVP will also review special conditions on a case-by-case basis.


[12-18-12] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS14.2). This version of the CAVS tool addresses minor updates:

  1. KAS ECCCDH Primitive Component: Modified code that creates txt file for website to include IUT's private key in the file.
  2. KAS ECCCDH Primitive Component: ECCCDH Primitive Verify was erroneously requiring SHA as a prerequisite. ECCCDH Primitive Compoent testing does not require any prerequisites. This has been corrected.
  3. KASECC: Changed the IDD-KASPREREQUISITESECC screen. Indicates that ECDSA PKV is not needed for Public Key Generation. Also added ECCCDH Primitive prerequisite guidance. This did not require any code change. It is only text.
  4. HMAC: The key size boxes expecting values less than or greater than the block size would erroneously allow the block size. This has been corrected. It caused problems with the summary file.
  5. HMAC: In CheckMO changed 5 to NUM_HMAC_TESTS to account for the addition of the 2 new SHAs.
  6. HMAC: In CheckMO code for SHA512/256, there were some SHA224 labels that needed to be SHA256 and some indexes of 1 that needed to be 6.
  7. AES: Counter Mode - if internal counter is specified, description is required. The CAVS screen didn't force this restriction. It now requires a description other than "" or "n/a" if internal counter is selected.
  8. AES - Corrected bug to allow any forward cipher function to be used as prerequisite for AES Counter.
  9. RSA2 info in inf file: There were 4 lines that had 2 equal signs. These have been replace with 1 equal sign.
  10. RSA2VS document - More descriptive text explaining the requirements for each Key Generation option.
  11. TDES error. If generate tests for encrypt and then check for encrypt and decrypt, it would indicate in the log file that the decrypt files didn't exist. But in the Summary file, it would indicate everything passed successfully. And visa versa. The Summary file has been changed to reflect the error.
  12. CMAC - In inf file, this line: CMACVer_AES=False was in two places, before CMACVer_AES128=False and before CMACVer_AES192=False. The second occurance has been removed. This line only occurs at the begining of the CMACVer section.

The transition period ends March 18, 2013.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, SHA 512/224, SHA 512/256, HMAC with SHA 512/224, HMAC with SHA 512/256, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, and/or the ECDSA2 Signature Generation Component, the CST lab must use the CAVS 14.2 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 14.2 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through March 18, 2013.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 14.2 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 14.2.

The CAVP will also review special conditions on a case-by-case basis.


[10-02-12] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS14.1). This version of the CAVS tool addresses:

  1. Fixed bug in ECDSA2 pre-requisites for Key Pair Generation and Signature Generation to allow either DRBG or RNG instead of DRBG only.
  2. Changed format of CAVS-generated input 'K' in SP 800-135 SSH KDF testing. 'K' is now represented as an mpint, where the first four octets (bytes) are a length field. 'K' now matches format in the SSH RFCs.
  3. Fixed bug in HMAC key size lengths for HMAC SHA-512/224 and HMAC SHA-512/256.
  4. SNMP KDF second Engine ID field now automatically populated with same value as first Engine ID if second is left blank or is of invalid length.
  5. Fixed bug in RSA2 PKCS PSS Signature Generation Component testing.
  6. Added COUNT variable to RSA2 PKCS1.5 Signature Generation Component test files.
  7. Fixed bug in RSA2 Summary file for Component testing.
  8. Increased number of trials from 10 to 30 on the RSA2PKCS1.5 and PSS Signature Generation Component validation tests.
  9. Increased number of trials for all KDFs in SP800-135.
  10. Fixed minor bug in KAS. One of the sample files indicated MACData = ?. But during verify, CAVS was looking for MacData = (Note difference in label.)

The transition period ends January 2, 2013.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, SHA 512/224, SHA 512/256, HMAC with SHA 512/224, HMAC with SHA 512/256, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, and/or the ECDSA2 Signature Generation Component, the CST lab must use the CAVS 14.1 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 14.1 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through January 2, 2013.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 14.1 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 14.1.

The CAVP will also review special conditions on a case-by-case basis.


[08-28-12] -- Changed second bullet on CAVS 14.0 release instructions listed below for [08-20-12]. For any GCM/GMAC implementation validation request that doesn’t currently have a validation number assigned to it, where a lab has used a version of CAVS prior to CAVS 14.0 to create files, regardless if the values have been sent to the vendor or not, please regenerate the GCM/GMAC tests using CAVS 14.0 or CAVS12.2 following the instructions supplied to the laboratories. Additional information from the vender regarding the Plaintext and AAD lengths supported by the IUT will be required to complete the testing.


[08-20-12] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS14.0). This version of the CAVS tool addresses:

  1. Added validation testing for SHA-512/224 and SHA-512/256 as defined in FIPS 180-4
  2. Added validation testing for HMAC SHA-512/224 and HMAC SHA-512/256
  3. Added component testing for RSA Signature Generation primitive: a. for PKCS1.5. This tests the RSASP1 primitive function described in PKCS #1 v2.1: RSA Cryptography Standard (June 14, 2002) Section 5.2.1. This test uses the encoded message EM format used by PKCS1.5. b. for PKCS PSS. This tests the RSASP1 primitive function described in PKCS #1 v2.1: RSA Cryptography Standard (June 14, 2002) Section 5.2.1. This test uses the encoded message EM format used by PKCS PSS
  4. Added component testing for ECDSA2 Signature Generation primitive. This bypasses the hashing of the message by sending the hash value as the message
  5. Fixed bug in GCM pre-requisites. RNG/DRBG is only required if IV is generated internally using method in Section 8.2.2, "RBG-based Construction."
  6. Changed minimum allowed generated keying data length for ANS X9.63-2005 KDF from 112 bits to any length greater than 0.
  7. Modified GCM screen to require values of Plaintext and AAD lengths to be tested for zero-length (if supported by the IUT), values that are a multiple of 128 (if supported by the IUT), and values that are a non-multiple of 128 (if supported by the IUT)
  8. Fixed bug in inf file where KAS ECC NOKC KASECC__NOKC_EE_HMACSHA512=False when it should have =True. This only affected the inf file for automation. It did not affect the CAVS tool.
  9. Changed name of tab on KAS_ECC for the component testing from "800-56A Component Testing" to "Sect 5.7.1.2 ECC CDH Component Testing" to be more exact
  10. Enforce prerequisite of ECDSA Key Pair for ECCCDH Primitive Component testing. This prerequisite is required only if the Key Pair Generation option is selected on the "Select Functions Included in IUT..." button.
  11. Made changes to Cover letter information including: Division number changed to 773, Institute was spelled wrong in return address, Added Laboratory Name to first sentence, and at end of letter indicated "posted on Nfiles"...

The transition period ends November 20, 2012.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, SHA 512/224, SHA 512/256, HMAC with SHA 512/224, HMAC with SHA 512/256, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, and/or the ECDSA2 Signature Generation Component, the CST lab must use the CAVS 14.0 to validate the IUT.
  2. For any GCM/GMAC implementation validation request that doesn’t currently have a validation number assigned to it, where a lab has used a version of CAVS prior to CAVS 14.0 to create files, regardless if the values have been sent to the vendor or not, please regenerate the GCM/GMAC tests using CAVS 14.0. Additional information from the vender regarding the Plaintext and AAD lengths supported by the IUT will be required to complete the information on the screen.
  3. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 14.0 to create files and has already sent the sample and request files to the vendor, except in the case of GCM/GMAC (see 2 above), NIST will accept validations using this tool up through November 20, 2012.
  4. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 14.0 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 14.0.

The CAVP will also review special conditions on a case-by-case basis.


[05-30-12] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS12.2). This version of the CAVS tool addresses:

  1. Minor fix in HMAC Summary file.

The transition period ends August 30, 2012.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, the testing of the ECC DLC Primitive Component, SP800-108 KDF and/or the individual KDFs in SP800-135, the CST lab must use the CAVS 12.2 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 12.2 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through August 30, 2012.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 12.2 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 12.2.

The CAVP will also review special conditions on a case-by-case basis.


[05-22-12] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories(CAVS12.1). This version of the CAVS tool addresses:

  1. Corrected the displaying of the RSA2 Key Gen Summary file.<\p>
  2. Corrected the displaying of the DRBG and RNG prerequisites in the RSA and RSA2 cover pages.
  3. Added line to the RSA2 information in the inf file: Selected=False/True.
  4. Changed name of variables for 800-108 in inf file to contain KDF108_ prefix.
  5. Removed duplicate KDF_PipelineMode = True/False line in the inf file.
  6. Changed section header from 800-108KDF to KDF800_108.
  7. Added error checking to RSA Key Gen to handle when response file doesn't have all prime methods in file that are to be tested.
  8. Fixed problems with SP 800-135 KDF input parameter limits.
  9. Fixed error with DRBG input lengths that are not a multiple of 8 bits.
  10. Changed default nonce length to zero for CTR_DRBG with no derivation function (df). Nonce is not used.

The transition period ends August 22, 2012.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, the testing of the ECC DLC Primitive Component, SP800-108 KDF and/or the individual KDFs in SP800-135, the CST lab must use the CAVS 12.1 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 12.1 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through August 22, 2012.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 12.1 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 12.1.

The CAVP will also review special conditions on a case-by-case basis.


[03-23-12] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS12.0). This version of the CAVS tool addresses:

  1. Added validation testing for SP 800-108,
  2. Added component validation testing for the Key Derivation Functions included in SP 800-135,
  3. Fixed bug in name of file for files created for “All of 800-56A EXCEPT KDF” testing. An additional dash was in the file name between the scheme name and NOKC,
  4. For DSA2 domain parameter g, testing changed so that p, q, and domain_parameter_seed would only be generated by CAVS using a method that the IUT supports,
  5. For DSA2 domain parameter g, testing changed so that p, q, and domain_parameter_seed would only be generated by CAVS using a method that the IUT supports,
  6. KAS ECC and KAS FFC – if assurances were selected and then unselected, the check box indicating assurance selected would stay checked. This was changed in KASNoteTab to uncheck “assurance checked” if assurance was unselected after being selected,
  7. RSA1 KeyGen not printing RNG and DRBG prerequisite numbers on Cover Page. They are in the inf file correctly. This has been changed to make RNG and DRBG prerequisite info display on Cover Page,
  8. RSA2 KeyGen3.3. If only support fixed e value doesn’t do KAT test. The Generate works correctly. But the verify looks for the KAT test. This has been corrected. (If supports random e values, both KAT and other test is run. This works correctly. This difference has been updated in VS document as well and will be posted at time of CAVS release,
  9. RSA2 SigGenPKCSPSS entries in inf file: There was a repeating saltlen for 3072sha1. This has been removed,
  10. RSA2 inf fileentry changes: 4 lines have two = signs and there should be only one:
        a. RSA2_BothPC_TableC2==False change to RSA2_BothPC_TableC2=False
        b. RSA2_BothPC_TableC3==False change to RSA2_BothPC_TableC3=False
        c. RSA2_ProvPC_TableC2==False change to RSA2_ProvPC_TableC2=False
        d. RSA2_ProvPC_TableC3==False change to RSA2_ProvPC_TableC3=False
  11. RSA2 SigGenPSS. For modsize = 1024 bits and SHA512 bits, the length of the salt shall be 0 <= sLen <=hLen-2. That is, the length of the salt shall be a number from 0 to 62 bytes. This has now been changed on the SigGenPSS screen and code,
  12. For DRBG testing, the number of returned bits output by each generate call was changed from a fixed value of one output block length to a tester-selected length ranging from 1 to 32 (default = 4) output block lengths. This will exercise parts of some implementations not covered by previous tests and enable testing for other implementations that do not support generating a single output block per call to generate.

The transition period ends June 23, 2012.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, the testing of the ECC DLC Primitive Component, SP800-108 KDF and/or the individual KDFs in SP800-135, the CST lab must use the CAVS 12.0 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 12.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through June 23, 2012.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 12.0 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 12.0.

The CAVP will also review special conditions on a case-by-case basis.


[09-8-11] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS11.5). This version of the CAVS tool addresses:

  1. 186-3 RSA - Corrected bug in file formatting of RSA Key Generation using Random Primes that are Probably Prime (B.3.3) that was causing the verification of the file to fail.
  2. In 186-3 RSA Signature Verification, added the ability for the IUT to indicate they only support fixed pubic key e values. If they indicate they only support fixed public key values, they must enter at least one value for the public key. They may enter up to 2 values to be tested by the Signature Verification test. All tests will use these public key(s). If this option is not selected, the option "random public key values supported by IUT" must be selected. Then random public keys will be used for the Signature Verification test.
  3. Added an internal prime check to CAVS' 186-3 RSA provable prime generation routine. This does not affect validation of 186-3 RSA.
  4. Changed "Special Processing Request" field in Vendor Info to "Do not post on CAVP website" field. This was the intended purpose of the original "Special Processing Request" field.
  5. Added "Other Special Requests and Notes for CAVP" field to Vendor Info. This field is to be used for all other requests for special processing or notes about the implementation.

The transition period ends December 8, 2011.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, and/or the testing of the ECC DLC Primitive Component, the CST lab must use the CAVS 11.5 to validate the IUT.
  2. If a 186-3 RSA validation request for 186-3 RSA Key Generation using Random Primes that are Probably Prime (B.3.3) is in the processing of being validated (files have been generated using a tool prior to CAVS 11.5), please regenerate the files ONLY for this one test - for 186-3 KEYGEN using Random Primes that are Probably Prime (B.3.3). (NOTE this applies to files that have been sent to the vendor and files that have not been sent to the vendor.)
  3. For any algorithm validation (excluding 186-3 RSA Key Generation using Random Primes that are Probably Prime) where a lab has used a version of CAVS prior to CAVS 11.5 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through December 8, 2011.
  4. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 11.5 to create files and has not yet sent the appropriate files to the vendor, the only files you would need to regenerate using CAVS 11.5 are those associated with 186-3 RSA Key Generation using Random Primes that are Probably Prime (B.3.3). All other algorithms and tests are the same between CAVS 11.4 and CAVS 11.5.

The CAVP will also review special conditions on a case-by-case basis.


[08-10-11] -- Updated CAVP Frequently Asked Questions (FAQ) document.


[07-14-11] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS11.4). This version of the CAVS tool addresses a minor bug fix allowing validation testing for "All of 800-56A except KDF" test to be run.

The transition period ends October 14, 2011.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, and/or the testing of the ECC DLC Primitive Component, the CST lab must use the CAVS 11.4 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 11.4 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through October 14, 2011.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 11.4 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 11.4.

The CAVP will also review special conditions on a case-by-case basis.


[07-08-11] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS11.3). This version of the CAVS tool addresses:

  1. KAS - Corrected the order of the Uid and Vid in the Other Information field in the Validity Test files. The order of these id fields was not in the correct order ONLY when an IUT was being tested as the responder.
  2. KAS - Added error checking for the Static scheme (for both FFC and ECC) - the Other Information field must contain the Party U's nonce.
  3. DRBG - The options for prediction resistance support have changed. Implementations that do not support prediction resistance should check the box labeled "Prediction Resistance Not Enabled." Implementations that always use prediction resistance should check the box labeled "Prediction Resistance Enabled" and leave the other box unchecked. Implementations that allow prediction resistance to be either on or off should check both boxes.
  4. CMAC - Past versions of CAVS would occasionally generate values for the CMAC "Verify" tests for small (one byte) MACs that would pass when the fax file indicated they should fail. This has been fixed.
  5. 186-3 ECDSA DSA and RSA - Allow any approved random number generator (DRBG or RNG) to be prerequisites for all of the 186-3 algorithms.
  6. 186-3 RSA - B.3.6 Key Generation method uses prime factors Xp1, Xp2, Xq1, Xq2 that satisfy the length requirements listed in Table B.1. When generating a random number of the desired length, a zero sometimes occurred in the left most position making the length shorter than expected. This has been corrected by forcing a 1 in the left most position.
  7. Other minor bug fixes.

The transition period ends October 8, 2011.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, and/or the testing of the ECC DLC Primitive Component, the CST lab must use the CAVS 11.3 to validate the IUT.
  2. For any algorithm validation request (except those algorithms listed in 3 below) where a lab has used a version of CAVS prior to CAVS 11.3 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through October 8, 2011.
  3. For algorithm validation requests for KAS where the responder role is being tested, 186-3 RSA where Key Generation method Appendix B.3.6 Generation of Probable Primes with Conditions Based on Auxiliary Probable Primes is being tested, or CMAC implementations allowing 1 byte MACs: : If a lab has generated values for this using a version of CAVS prior to CAVS11.3, the CST must regenerate the files using CAVS11.3.
  4. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 11.3 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 11.3.

The CAVP will also review special conditions on a case-by-case basis.


[05-18-11] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS11.2). This version of the CAVS tool addresses:

  1. Several bug corrections.

The transition period ends August 18, 2011.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, and/or the testing of the ECC DLC Primitive Component, the CST lab must use the CAVS 11.2 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 11.2 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through August 18, 2011.
  3. For algorithm validation requests for SP800-56A using FFC Static scheme or ECC StaticUnified scheme: If a lab has generated values for this using a version of CAVS prior to CAVS11.2, the CST must regenerate the files using CAVS11.2.
  4. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 11.2 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 11.2.

The CAVP will also review special conditions on a case-by-case basis.


[04-12-11] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS11.1). This version of the CAVS tool addresses:

  1. Added DLC primitive only testing to the KAS ECC screen. This tests the functions of the Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH) Primitive as a component. This means only the function ECC CDH is tested.
  2. Changed the labeling of the existing testing that WAS called “DLC Primitive only” to “All of SP800-56A EXCEPT KDF” which better describes the actually testing.
  3. Correctly labeled what WAS called “Assurances” to “Supporting functions included in the IUT that aren’t described in SP800-56A”, (e.g., DSA Key Generation, etc.)
  4. Increased the number of iterations for each round of FIPS186-3 RSA Key Generation.
  5. Corrected a bug in KASFFC that affected the prerequisites expected. When “Full Public Key Validation” is selected, CAVS erroneously required DSA as a prerequisite. This is not true and has been corrected.

The transition period ends July 12, 2011.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, and/or the testing of the ECC DLC Primitive Component, the CST lab must use the CAVS 11.1 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 11.1 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through July 12, 2011.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 11.1 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 11.1.

The CAVP will also review special conditions on a case-by-case basis.


[03-03-11] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS11.0). This version of the CAVS tool addresses:

  1. Addition of Validation testing for 186-3 RSA
  2. Removal of the Assurances from the 186-3DSA and ECDSA validations. The selection of testing functions denotes whether or not an assurance could be met. The assurances are out of scope of the algorithm implementation.
  3. Removal of the Assurances from the KAS validations. The selection of testing functions denotes whether or not an assurance could be met. The assurances are out of scope of the algorithm implementation.
  4. Removal of the Assurance that "An XTS-AES key shall not be associated with more than one key scope." from XTS. This is out of scope of the algorithm implementation.
  5. Correction of bug in GCM which denoted a correct answer as wrong. Caused by truncation of answer and the first couple bytes matching the correct answer.
  6. Addition of information to the log file for GCM Decrypt to indicate why a value fails
  7. Modification of wording for prerequisite of AES for GCM. Prerequisite for AES said only ECB. Changed wording to include any mode with forward cipher function. This includes ECB and CBC encrypt, CFB and OFB encr and decr and CTR (which requires ECB so is really ECB).
  8. Removal of prerequisite of DRBG from ECDSA2 SigVer. Removed from Verify function because it would not verify because didn't have DRBG specified. Also removed from cover letter.
  9. The ECDSA Prerequisite screen is shared between ECDSA and ECDSA2. ECDSA can use RNG but ECDSA2 can not. The bug that prevented ECDSA from specifying an RNG prerequisite has been corrected.
  10. Other minor modifications.

The transition period ends June 3, 2011.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, and/or XTS, the CST lab must use the CAVS 11.0 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 11.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through June 3, 2011.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 11.0 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 11.0.

The CAVP will also review special conditions on a case-by-case basis.


[06-07-10] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS10.1). This version of the CAVS tool addresses a correction to the Key Agreement Schemes ECC with No Key Confirmation (KAS ECC No KC) screen. (When parameter set EA was selected, the radio button for the curve size would only allow P-192 to be selected.) This has been corrected.

The transition period ends September 7, 2010.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, 186-2 DSA, SHA, RNG, RSA, HMAC, CCM, 186-2 ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, 186-3 DSA, 186-3 ECDSA and/or XTS, the CST lab must use the CAVS 10.1 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 10.1 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through September 7, 2010.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 10.1 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 10.1.

The CAVP will also review special conditions on a case-by-case basis.


[05-27-10] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS10.0). This version of the CAVS tool addresses

  1. Validation testing for FIPS 186-3 ECDSA
  2. Addition of prerequisites for KAS
  3. Addition of error checking on the values entered for KAS, CCM, and CMAC to assure they are valid values
  4. Fixed a bug in KAS ECC when EE parameter set was used
  5. Removed some extraneous information in the cover letter
  6. XTS restriction on Data Unit Length – enforcing the minimum to be block size
  7. Modified format of Summary files to aid us in the automation of NIST’s internal database. This should be transparent to the testing laboratories and the processing of the CAVS tool. Included adding additional fields to coincide with the importing of information on the validation lists.

The transition period ends August 27, 2010.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, 186-2 DSA, SHA, RNG, RSA, HMAC, CCM, 186-2 ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, 186-3 DSA, 186-3 ECDSA and/or XTS, the CST lab must use the CAVS 10.0 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 10.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through August 27, 2010.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 10.0 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 10.0.

The CAVP will also review special conditions on a case-by-case basis.


[03-31-10] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS9.0). This version of the CAVS tool addresses

  1. Addition of validation test for NIST SP 800-38E: XTS-AES Mode for Confidentiality on Storage Devices
  2. Addtion of tests for FIPS 186-3 Section A.1.2, "Construction and Validation of the Provable Primes p and q," FIPS 186-3 Section A.2.3, "Verifiable Canonical Generation of the Generator G,", and FIPS 186-3 Section A.2.4, "Validation Routine when the Canonical Generation of the Generator G was Used."
  3. Modification of GCM Tab to allow zero-length AAD (min and max length of AAD can now be equal to zero)
  4. Modification of GCM Tab to allow selection of both methods for IV generation 8.2.1 and 8.2.2 instead of only one.
  5. In response to Implementation Guidance D.2 Acceptable Key Establishment Protocols, which states that an implementation of SP800-56A can use additional key derivation functions (KDFs) specified in D.2 that are not included in SP800-56A, addition of validation tests that test the processing of all functions up to and including the calculation of the shared secret value (Z) in SP800-56A. This testing is required for implementations adhering to D.2 to assure that the other processing that adheres to the specifications in SP800-56A is correct. These implementations will not receive a KAS Validation. But they will be acknowledged for going through the testing.
  6. Additional information is being requested on the screens for SP800-56A to satisfy the CAVS-addressable requirements in the special publication.
  7. Addition of the entry of prerequisites for most algorithms. This enforces that the laboratory has supplied the source of the prerequisite algorithms.
  8. Correction of a minor bug and pointer problem in ECDSA
  9. Modified format of summary files to aid the CAVP in the automation of the CAVP's internal database.

The transition period ends June 30, 2010.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, HMAC, CCM, ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA2 and/or XTS, the CST lab must use the CAVS 9.0 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 9.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through June 30, 2010.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 9.0 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 9.0.

The CAVP will also review special conditions on a case-by-case basis.


[09-17-09] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS8.1). This version of the CAVS tool addresses several minor modifications and enhancements to CAVS including the Addition of a cover letter template, the addition of more efficient elliptic curve routines for NIST binary (e.g.., B-163 and K-571) curves, and the modification of several minor issues.

The transition period ends December 17, 2009.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, HMAC, CCM, ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D and/or FIPS186-3 DSA2(see exception below in 2), the CST lab must use the CAVS 8.1 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 8.1 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through December 17, 2009.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 8.1 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 8.1.

The CAVP will also review special conditions on a case-by-case basis.


[08-17-09] -- Posting of the CAVS Management Manual. The purpose of the CAVP Management Manual is to provide effective guidance for the management of the CAVP and other parties in the validation process. The CAVP Management Manual applies to the CAVP Validation Authorities, the CST laboratories, and the vendors who participate in the program. Consumers who purchase validated cryptographic modules and validated cryptographic algorithm implementations may also be interested in the contents of this manual. This manual outlines the management activities and specific responsibilities of the various participating groups. This manual does not include any cryptographic standards.


[07-02-09] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS8.0). This version of the CAVS tool activates the FIPS 186-3 DSA2 validation testing with the exception of generation and validation of provably prime domain parameters p and q and canonical generation and validation of domain parameter g. It also requires the IUT to specify the assurances necessary for valid digital signatures specified in FIPS 186-3.

The transition period ends October 02, 2009.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, HMAC, CCM, ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D and/or FIPS186-3 DSA2 (see exception below in 2), the CST lab must use the CAVS 8.0 to validate the IUT.
  2. Implementations of FIPS186-3 DSA2 supporting the generation and validation of provably prime domain parameters p and q and canonical generation and validation of domain parameter g, ECDSA2 and/or RSA2 must be vendor-affirmed according to the specifications in I.G 1.15. All new DSA2 implementations supporting the above listed domain parameter generation and validation methods, ECDSA2 and RSA2 algorithm validation requests received after the release of CAVS8.0 shall be vendor affirmed.
  3. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS8.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through October 2, 2009.
  4. If there are any validation requests where a lab has used a version of CAVS prior to CAVS8.0 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS8.0.

The CAVP will also review special conditions on a case-by-case basis.


[04-15-09] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS7.4). This version of the CAVS tool adds the capability to test DRBG (NIST SP 800-90) implementations that do not have the optional reseed function. Each DRBG mechanism tab has a check box to indicate that the reseed function was not implemented. If checked, the generated request files provide inputs for the instantiate and generate functions only. The CAVS-generated TestedInfo.txt file indicates that the implementation does not support the reseed function.

The transition period ends July 06, 2009.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, HMAC, CCM, ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC and/or GCM 800-38D, the CMT lab must use the CAVS 7.4 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS7.2 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through July 6, 2009. (Note that the transition date for CAVS 7.4 will be the same as CAVS 7.2 and CAVS 7.3.)
  3. Because CAVS 7.4 makes a very minor addition that does not affect any existing operations of the tool, for any algorithm validation request where a lab used CAVS 7.2 or CAVS 7.3 to create files, CAVS 7.4 can be used to validate these files.
  4. If there are any validation requests where a lab has used a version of CAVS prior to CAVS7.2 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 7.4.

The CAVP will also review special conditions on a case-by-case basis.


[04-08-09] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS7.3). This version of the CAVS tool fixes a bug in the Utilities->Display Status function. The bug caused CAVS to end abnormally.

The transition period ends July 06, 2009.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, HMAC, CCM, ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC and/or GCM 800-38D, the CMT lab must use the CAVS 7.3 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS7.2 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through July 6, 2009. (Note that the transition date will be the same as CAVS7.2.).
  3. Because CAVS7.3 fixes a very minor bug that only affects the ability to display the status of the tests and not the other operations of the tool, for any algorithm validation request where a lab used CAVS7.2 to create files, CAVS7.3 can be used to validate these files.
  4. If there are any validation requests where a lab has used a version of CAVS prior to CAVS7.2 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 7.3.

The CAVP will also review special conditions on a case-by-case basis.


[04-06-09] -- New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS7.2). Version 7.2 of the CAVS tool includes several minor corrections and additions. They include:

  1. Minor correction to KAS ECC screen - corrected the wording on the screen - min of h should be max of h
  2. Minor correction to KAS ECC testing - corrected the length of a field which was causing KAS EEC testing to exit abnormally
  3. In the TestedInfo.txt file, added prerequisite of RNG to GCM if option 2 is selected
  4. In the TestedInfo.txt file, added statement for CMAC to ask for the prerequisite of TDES and/or AES, if applicable.
  5. Modified the SHA screen to allow the indication of "null string not supported".
  6. Modified the SHA screen to only have to enter "Byte only" once to apply to all supported SHA sizes.

The transition period ends July 06, 2009.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, HMAC, CCM, ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC and/or GCM 800-38D, the CMT lab must use the CAVS 7.2 to validate the IUT.
  2. For any algorithm validation request where a lab has used a previous version of CAVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through July 06, 2009. The tool used to generate the files must be used to validate the files. For example, if CAVS7.1 was used to generate test vectors, then CAVS7.1 must be used to verify these values.
  3. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS7.2.

The CAVP will also review special conditions on a case-by-case basis.


[03-12-09] -- New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS7.1). In addition to minor modifications to enhance the tool, Version 7.1 of the CAVS tool adds testing for the draft of FIPS 186-3, Digital Signature Standard, Digital Signature Algorithm and file formating changes to the NIST SP 800-90 (DRBG) files to make them more similar to those used for other algorithms. As of the CAVS 7.1 release date, FIPS 186-3 is still in draft. No validations will be processed for this algorithm.

The transition period ends June 12, 2009.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, HMAC, CCM, ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC and/or GCM 800-38D, the CMT lab must use the CAVS 7.1 to validate the IUT.
  2. For any algorithm validation request where a lab has used a previous version of CAVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through June 12, 2009. The tool used to generate the files must be used to validate the files. For example, if CAVS7.0 was used to generate test vectors, then CAVS7.0 must be used to verify these values.
  3. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS7.1.

The CAVP will also review special conditions on a case-by-case basis.


[12-24-2008] -- New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS7.0). Version 7.0 of the CAVS tool adds testing for NIST SP 800-56A Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography and NIST SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.

  1. In addition, file formating changes have been made to the CCM Decrypt-Verification Process Test.

The transition period ends March 24, 2009.

As has been the policy in the past:

  1. For any algorithm validation request where a lab has used a previous version of CAVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through March 24, 2009. The tool used to generate the files must be used to validate the files. For example, if CAVS6.1 was used to generate test vectors, then CAVS6.1 must be used to verify these values.
  2. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS7.0.

Prior to the release of CAVS7.0, the CMVP allowed vendor affirmation for SP800-56A implementations (IG1.12) and vendor affirmation for SP 800-38D implementations (IG.1.13). During the transition period, the vendor has the option of either providing the vendor affirmation in FIPS 140-2 IG1.12 or IG1.13 or going through the validation testing now available in CAVS7.0. The transition period for accepting vendor affirmation for SP 800-56A is being determined but will exceed the 3 months specified above. Please see the CMVP Announcements for further information.

The CAVP will also review special conditions on a case-by-case basis.


[02-06-2008] -- New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS6.1). The CAVS 6.1 tool fixes an error with HMAC_DRBG SP 800-90 DRBG testing. CAVS 6.0 was erroneously using the Hash_DRBG mechanism to generate returned bits for the HMAC_DRBG tests in the .fax files. A second modification made to CAVS6.1 regarding SP 800-90 DRBG testing involved changing the requested number of bits to always be a multiple of the blocksize.

With regards to DSA validation testing, CAVS6.1 DSA screens have been modified to only allow modulus sizes providing at least 80 bits of security as required by SP800-57; i.e., only the 1024 bit modulus size is allowable.

The transition period ends May 6, 2008.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, DRBG, RSA, ECDSA, HMAC, CCM and/or CMAC, the CMT lab must use the CAVS 6.1 to validate the IUT.
  2. For any algorithm validation request where a lab has used a previous version of CAVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through May 6, 2008.
  3. The exception to (2.) above is SP 800-90 DRBG testing for the HMAC_DRBG mechanism using any SHA size. CAVS 6.1 must be used for all HMAC_DRBG validation submissions.
  4. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 6.1.

[11-15-2007] -- New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS6.0). Verison 6.0 of the CAVS tool adds testing for NIST SP 800-90 Deterministic Random Bit Generators.

The transition period ends February 15, 2008.

As has been the policy in the past:

  1. For any algorithm validation request where a lab has used a previous version of CAVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through February 15, 2008. The tool used to generate the files must be used to validate the files. For example, if CAVS5.3 was used to generate test vectors, then CAVS5.3 must be used to verify these values.
  2. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS6.0.

Prior to the release of CAVS6.0, the CMVP allowed vendor affirmation for SP 800-90 DRBG implementations. During the transition period, the vendor has the option of either providing the vendor affirmation in FIPS 140-2 IG1.12 or going through the validation testing now available in CAVS6.0. Please see the CMVP Announcements for further information.

The CAVP will also review special conditions on a case-by-case basis.


[10-16-2006] [09-28-2006] New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS5.2). Version 5.2 of the CAVS tool includes the addition of tests to verify the absence of an identified RSA X9.31 and PKCS#1 V1.5 algorithmic implementation vulnerability. Information on this vulnerability can be found at the Computer Security Resource Center (CSRC 2006 Archive News page) October 12, 2006 News. A statement discussing the attack is available. CAVS5.2 also includes several modifications to the existing algorithm validation tests to provide requested enhancements to the tool. Additional information can be found at: Digital Signature Standard (DSS)

The transition period ends December 31, 2006.

As has been the policy in the past:

  1. For any algorithm validation request where a lab has used a previous version of CAVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through December 31, 2006.
  2. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS5.2.
  3. It is strongly advised that any CMVP cryptographic module in the pre-validation phase re-test the RSA implementations with the new version of CAVS.
  4. After December 31, 2006, all new received test reports to the CMVP pre-validation queue must use the CAVS5.2 to validate RSA.

The CAVP will also review special conditions on a case-by-case basis.

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

  1. If new CAVP testing is performed, and the vulnerability is determined not to be present, the CMTL can send a letter to the CAVP along with the ZIP'ed CAVS 5.2 files requesting a new algorithm certificate printed to replace the already issued certificate referencing the new version of CAVS. Note that the certificate number will not change. Only the reference to the version of the CAVS tool will be changed.
  2. If CAVP testing is performed and the vulnerability is discovered, the following revalidation process shall be followed:
    1. The algorithm implementation is changed to remove the vulnerability resulting in a different version number,
    2. 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.
    3. A revalidation letter can be submitted to the CMVP confirming that the only change to the module is to the RSA algorithmic implementation to correct the identified vulnerability; provide the reference to the new RSA algorithmic validation certificate; and provide a new version for the module. The CMVP will update the existing FIPS 140-1 or FIPS 140-2 module certificate web site entry to reference the new RSA algorithmic validation certificate and the new module version number associated with that certificate. No new FIPS 140-2 validation certificate will be issued. An updated Security Policy is required to include the new information. Any other changes to the validated cryptographic module shall handled in accordance with IG G.8 - Revalidation Requirements.

Please direct any CAVP or CMVP questions to the appropriate contact.


[04-03-2006] New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS5.0).Version 5.0 of the CAVS tool includes the addition of a validation test suite for the CMAC algorithm. Documentation describing the CMAC validation tests is located in the CMACVS document accessible via our webpage. CAVS5.0 also includes several modifications to the existing algorithm validation tests to provide requested enhancements to the tool.

The transition period ends July 3, 2006.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, ECDSA, HMAC, CCM and/or CMAC, the CMT lab must use the CAVS5.0 to validate the IUT.
  2. For any algorithm validation request where a lab has used a previous version of CAVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through July 3, 2006.
  3. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS5.0.

The CAVP will also review special conditions on a case-by-case basis.


[05-11-2005] New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS4.6). Version 4.6 of the CAVS tool includes a couple of minor modifications. These modifications include:

The transition period ends July 3, 2006.

As has been the policy in the past:

  1. For HMAC: Enforcing the minimum length allowed for the key size. As specified by FIPS PUB 198 The Keyed-Hash Message Authentication Code (HMAC) Section 3 Cryptographic Keys, it states: "The size of the key, K, shall be equal to or greater than L/2, where L is the size of the hash function output." The minimum key size is dependent on the hash function supported by the HMAC implementation and is specified on each screen for HMAC.
  2. For DES and Triple-DES: The message displayed after validating results has been modified to indicate whether or not the tests have passed successfully.

The transition period ends August 11, 2005.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of DES, Triple-DES, AES, DSA, SHS, RNG, RSA, ECDSA, HMAC and/or CCM, the CMT lab must use the CAVS4.6 to validate the IUT.
  2. For any algorithm validation request where a lab has used CAVS4.5 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool during the transition period which expires August 11, 2005. The CMT Laboratory should contact those vendors to inform them that the algorithm validation files supplied to them will expire at the end of the transition period. If the vendor has not returned the response files by that time, the request and sample files will have to be regenerated by the CAVS4.6 tool and the vendor will have to regenerate the response files.
  3. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not sent the appropriate files to the vendor yet, please regenerate everything using CAVS4.6.

The CAVP will also review special conditions on a case-by-case basis.


[01-31-2005] New release of the CAVS algorithm validation testing tool to the CMT Laboratories

  1. New RNG algorithm testing
    • Algorithm testing available for NIST-Recommended Random Number Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES Algorithms.
    • During the transition period, ANSI X9.31 RNG implementations using 3-Key Triple-DES and AES algorithms will continue to be recognized as FIPS Approved "vendor affirmed" or referenced to the new algorithm certificate if available for FIPS 140-2 validations. After the transition period, these RNG implementations will only be recognized on new FIPS 140-2 validations as FIPS Approved when referenced to an algorithm certificate.
    • All references to RNG on FIPS 140-2 validation certificates that have RNG certificates will be referenced as RNG (Cert. nnn).

The transition period ends April 30, 2005. New FIPS 140-2 validation test reports received from CMT Laboratories after the transition period must conform to the new algorithm testing schemes indicated above. For FIPS 140-2 re-validations received after April 30, 2005, if the security relevant changes do not require new algorithm testing, new algorithm testing is not required. If an algorithm is changed or added, that algorithm must conform to the new algorithm testing schemes indicated above.

For algorithm validation requests where a CMT Laboratory has used CAVS4.3 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using the old tools during the transition period. The CMT Laboratory should contact those vendors to inform them that the algorithm validation files supplied to them will expire at the end of the transition period. If the vendor has not returned the response files by that time, the request and sample files will have to be regenerated by the CAVS4.4 tool and the vendor will have to regenerate the response files. The CMVP will also review special conditions on a case-by-case basis.


[09-01-2004] New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS4.0).

  1. New ECDSA algorithm testing
    • Testing is now available for conformance to the ECDSA algorithm.
    • During the transition period, ECDSA algorithms will continue to be recognized as FIPS Approved "vendor affirmed" or referenced to the new algorithm certificate if available for FIPS 140-2 validations. After the transition period, ECDSA will only be recognized on new FIPS 140-2 validations as FIPS Approved when referenced to an algorithm certificate.
    • All references to ECDSA on FIPS 140-2 validation certificates that have ECDSA certificates will be referenced as ECDSA (Cert. nnn).
  2. New HMAC algorithm testing
    • Testing is now available for conformance to the HMAC algorithm.
    • During the transition period, the HMAC algorithm will continue to be recognized as FIPS Approved "vendor affirmed" or referenced to the new algorithm certificate if available for FIPS 140-2 validations. After the transition period, HMAC will only be recognized on new FIPS 140-2 validations as FIPS Approved when referenced to an algorithm certificate.
    • All references to HMAC on FIPS 140-2 validation certificates that have HMAC certificates will be referenced as HMAC (Cert. nnn).
  3. New CCM algorithm testing
    • Testing is now available for conformance to the CCM algorithm.
    • CCM will only be recognized on new FIPS 140-2 validations as FIPS Approved when referenced to an algorithm certificate.
    • All references to CCM on FIPS 140-2 validation certificates will have CCM certificates and will be referenced as CCM (Cert. nnn).

The transition period ends December 1, 2004. New FIPS 140-2 validations or re-validation test reports (RE: FIPS 140-2 IG G.8) received from CMT Laboratories after the transition period must conform to the new algorithm testing schemes indicated above and meet ALL current standards and IGs.

For algorithm validation requests where a CMT Laboratory has used CAVS3.3 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using the old tools during the transition period. The CMT Laboratory should contact those vendors to inform them that the algorithm validation files supplied to them will expire at the end of the transition period. If the vendor has not returned the response files by that time, the request and sample files will have to be regenerated by the CAVS4.0 tool and the vendor will have to regenerate the response files. The CMVP will also review special conditions on a case-by-case basis.


[06-14-2004] New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS 3.3).

  • Added Key Generation to RSA X9.31.
  • Added validation tests for the General Purpose RNG specified in FIPS 186-2 Change Notice.
  • Added the ability to select more than one SHA when running validation tests for RSA. This has changed the format of the Signature Generation and Signature Verification files.

[03-11-2004] New release of the CAVS algorithm validation testing tool to the CMT Laboratories.

New and Updated Implementation Guidance:

  • New rDSA algorithm testing
    • Testing is now available for conformance to several versions of the rDSA algorithm.
    • During the transition period, rDSA algorithms will continue to be recognized as FIPS Approved "vendor affirmed" or referenced to the new algorithm certificate if available for FIPS 140-2 validations. After the transition period, rDSA will only be recognized on new FIPS 140-2 validations as FIPS Approved when referenced to an algorithm certificate.
    • All references to RSA on FIPS 140-2 validation certificates that have rDSA certificates will be referenced as rDSA (Cert. nnn).
  • Expanded SHS algorithm testing
    • Testing is now available for conformance to SHA-1, SHA-256, SHA-384, and SHA-512 algorithms.
    • SHS algorithms will only be recognized as FIPS Approved with reference to an algorithm certificate.
    • All references to Secure Hash Algorithms on FIPS 140-2 validation certificates that have SHS certificates will be referenced as SHS (Cert. nnn).
  • New RNG algorithm testing
    • Testing is now available for conformance to the RNG algorithms that are referenced in FIPS 140-2 Annex C.
    • During the transition period, FIPS Approved RNG's found in FIPS 140-2 Annex C that do not have an algorithm certificate can still be used in FIPS Approved mode and will not be listed on the FIPS 140-2 validation certificate. They will only be listed on the FIPS 140-2 validation certificate if an algorithm certificate is available. After the transition period, FIPS Approved algorithms that can be tested can only be used in a FIPS Approved mode with reference to an algorithm certificate. Where testing is not available for the FIPS Approved algorithms, they will be annotated as "vendor affirmed".
    • All references to RNG algorithms on FIPS 140-2 validation certificates will be referenced as RNG (Cert. nnn).

The transition period ends June 04, 2004. New FIPS 140-2 validations or re-validation test reports (RE: FIPS 140-2 IG G.8) received from CMT Laboratories after the transition period must conform to the new algorithm testing schemes indicated above and meet ALL current standards and IGs.

For algorithm validation requests where a CMT Laboratory has used CAVS1.3 or DSSVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using the old tools during the transition period. The CMT Laboratory should contact those vendors to inform them that the algorithm validation files supplied to them will expire at the end of the transition period. If the vendor has not returned the response files by that time, the request and sample files will have to be regenerated by the CAVS3.0 tool and the vendor will have to regenerate the response files. The CMVP will also review special conditions on a case-by-case basis.