Computer Security Resource Center

Computer Security Resource Center

Computer Security
Resource Center

Cryptographic Algorithm Validation Program

2014 Announcements

[12-23-14] -- Updated SP800-56A Key Agreement Schemes (KAS) Test Vectors.

[12-8-14] -- CAVP request that CST Laboratories assure the accuracy of the vendor and implementation information given for cryptographic algorithm implementation validation requests; i.e., Vendor URL, etc.

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

  1. SP800-38F:  Error corrected in authenticatedDecryptionTest
  2. SP800-135: IKEv2 minimum for nonce and payload should be 128 bits instead of 64 bits

The transition period ends March 8, 2015.

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.4 to validate the IUT.
  2. For any algorithm validation request where a lab has used CAVS 17.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 March 8, 2015. 
  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.4.

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

[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 CAVS. 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 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 (CAVS). 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 CAVS 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 .

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. 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. 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, 2015.
  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. 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.

 

Created October 05, 2016, Updated February 09, 2018