Computer SecurityResource Center

Cryptographic Algorithm Validation Program

Project Links

2015 Announcements

[12-29-15]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS18.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 Revision 1 Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths) effective January 1, 2016. It also includes several corrections to existing bugs. The following changes have been made :

SP800-131A Revision 1 - Transitions

Remove RNG tab

Remove TDES KO2 Encrypt from all modes

Remove CMAC - TDES KO2 from encrypt screen

Remove KBKDF - CMAC 2Key TDES from all modes

Remove all RNG prerequisites

DSA2, ECDSA2 and RSA2 - Remove affirmation of Generation with SHA1 used for protocol.ÂÂÂÂ This is out of scope at this level (as discussed at 2015 CAVP/CMVP Manager’s meeting).

RandPrim - test has different error checking than the rest of the prime tests.

RSA2 Key Generation Fixed operations of OK, Cancel and Deactivate and how they are listed in the inf file. They were being incorrectly reported in the inf file.

RSA2 Key Generation using Probable Primes wasn't creating files if old or new format wasn't checked. Old or new format shouldn't have to be checked for probable prime files to be created. This has been fixed.

RSADP - Assure the CT value generated by CAVS is the length of the mod.

KAS FFC - when Full Val selected, shouldn't ask for prerequisite of DSA. This has been corrected.

KAS ECC - Fixed bug in MACdata when P-521 produces short key values (AssignKCValue function). When it concatenated all the fields together, it was putting an erroneous value in the beginning byte of the ephem pub key.

KAS ECCCDH component doesn't require any prerequisites unless functions Key Pair Generation or Re-generation are included in the IUT. Then ECDSA Key Pair Generation is a prerequisite. It was erroneously asking for SHA and DRBG. This has been corrected in CAVS.

GCM screen - Values entered on screen are saved when select Save. If there is an error in a value (for example, if value entered is not a multiple of 8) it was erasing everything from this value on. Now it is not checking the accuracy of the values until Generate GCM is selected.

GCM error message - made more descriptive.

The transition period ends March 29, 2016.

As has been the policy in the past:

EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, 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 CAVS18.0 to validate the IUT.(Note: The RNG algorithm has been removed from this list because SP800-131A Revision 1 states that the RNG algorithm is non-compliant beginning January 1, 2016. In the rare situation where an RNG implementation is to be validated between December 29, 2015 and January 1, 2016 and values have not been generated, CAVS17.9 may be used to generate them. If the validation is submitted before January 1, 2016 and it successfully passes the validation tests, this implementation will receive an RNG validation on the Historical RNG Validation List but it will be non-compliant. RNG validations will not be accepted after December 31, 2015.)

For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 18.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations of acceptable algorithms using this tool up through March 29, 2016. If an IUT validated with CAVS 17.9 contains any of the above disallowed features as of December 31, 2015, these disallowed features will not be accepted. If the validation date is before January 1, 2016, the RNG validation will appear on the Historical RNG Validation List but it will be non-compliant.

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 18.0.

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

In RSADP, initialized testallconditions to TRUE.

Removed Dual ECDRBG.

Re-added testing for SHA1 for all digital signatures using SHA-1 for use with protocols.

Added affirmation check box required by IUT to assure that SHA1 with digital signature is being used for protocol use only. Also specified that these are protocols as specified by NIST protocol-specific guidance.

For HMAC-SHA256, when a MAC size of 24 Bytes was selected in the HMAC tab the TestedInfo.txt file shows a MAC size of 26 Bytes instead. This typo has been fixed.

For RSA2 FIPS 186-2 - Legacy PKCS PSS Signature Verification: the -Salt Value= line header was not being printed. The value was printed though on the same line as the salt length. (If the salt value was NULL, a zero was being adhered on the end of the salt length making it look like the salt length was multiplied by 10. (16 became 160) ) This has been corrected so it will look like this: Salt Length = 16. On next line it will say Salt Value = 0.

RSA2 FIPS 186-2 Key Gen testing - Was linked to - New Format code: so wouldn’t create files if New Format was not checked. New Format does not apply to FIPS 186-2 testing. This has been corrected to not need New Format checked. Only FIPS 186-2 Key Gen needs to be selected which brings up a window where information must be entered

Removed box around RSA mod 4096 as only allowed for revalidations because update to FPS 186-4 in future is going to put an explicit statement in these standards about allowing longer keys

For any algorithm validation request where a lab has used CAVS 17.8 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, 2015.

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.9.

[06-16-15] -- Removed statement "This requirement must be enforced at the module or product level." from TDES testing announcement posted 06-04-15. The statement should read "As always, even though guidance included in a NIST publication is not testable at the algorithm level, this does not mean it can be ignored."

[06-16-15]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS17.8). CAVS 17.7 WILL NOT BE USED BECAUSE OF A MINOR BUG FIX. The following modification has been made:

For any algorithm validation request where a lab has used CAVS 17.6 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 16, 2015.

For any algorithm validation request where a lab has used CAVS 17.7 to create files, please regenerate everything using CAVS 17.8.

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.8.

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

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

RSA2 - Reports of non prime numbers were found in the CAVS test value files when all the numbers should have been prime. The reason was discovered and was corrected. It was caused by more than one error code being assigned to distinguish between different types of errors but only one error code (FAILURE) being processed.

RSA2 - Function C.9 has RSA_BAD800_90 error code if genRand800-90 fails. Changing this to FAILURE so only has one error code returned from Function C.9.

For any algorithm validation request where a lab has used CAVS 17.6 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 16, 2015.

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

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

[06-04-15]--On February 5, 2015, guidance was posted indicating that there was going to be a change in the TDES algorithm validation testing to support the statement in NIST SP 800-67 Revision 1, dated January 2012 - A key bundle shall not consist of three identical keys. Phase 1 of this guidance was completed and is included in CAVS 17.5 which was released March 4, 2015. This included:

Removing the radio button to select Keying Option 3;

Modifying the Monte Carlo and MMT validation tests to remove the use of Keying Option 3 (where K1=K2=K3).

It has been determined that Phase 2 of this guidance posted on February 5, 2015 will not be done.Â The use of a key bundle consisting of three identical keys in the Known Answer tests is used to test the underlying DES engine(s) in a TDES implementation. The values used for the key and the text for the second and third rounds of the TDES function must be controlled to assure that the targeted components of the TDES algorithm are being tested. The Known Answer test values for TDES, which are based on the Known Answer test values designed initially for DES, assure this. Therefore an implementation must have the ability to use a key bundle consisting of three identical keys for validation testing purposes.

The requirement: A key bundle shall not consist of three identical keys is not testable at the algorithm level.Â As always, even though guidance included in a NIST publication is not testable at the algorithm level, this does not mean it can be ignored.

[03-16-15]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS17.6). The following modifications have been made:

SP800-135 - The screens for IKEv1 and IKEv2 were too short to hold all the information and therefore the information was being truncated. The screen length has been increased to show all the information.

For any algorithm validation request where a lab has used CAVS 17.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 June 16, 2015.

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.6.

[03-04-15] -- Updated the SRTP section of The SP800-135 Validation System document.

[03-04-15]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS17.5). The following modifications have been made:

New Information Added to Vendor/Implementation screen: This additional cryptographic algorithm testing information addresses how and by whom the algorithm testing was performed.

RSA2 - In the inf file the section for Legacy RSA information, the label had a space in the middle of it. The space has been removed. ( Legacy_PKCS#1_15SigVer had a space after it and before = or _mod or _SHA - ex. Legacy_PKCS#1_15SigVer _mod1024)

In GCM section of inf file moved Selected=True/False to first line of section. Now consistent with other sections.

In GCM section changed [AES GCM] to [GCM]. Code will accept both labels as input but will replace with only GCM for future. That way code will read older files created with other tool.

800-135 SRTP - added ability to select subset of possible KDR values

800-135 SRTP – wasn’t checking that 2^24 is supported when select all values. Corrected this

800-135 SRTP - When verifying, assumed the given values from the request file were entered correctly so didn’t check their accuracy. I’ve changed this so it will detect differences between the given values and the values that should have been repeated exactly in the response file.

800-135 SRTP - Modified Log file to be more descriptive.

ECDSA2 and ECDSA2SigGenComponent - In the inf file have these fields separated in the inf file since they get different validations (either ECDSA or Component). But when imported into the CAVS tool, they populate the same screen.

ECDSA2 SigGen verification of SHA512/224 and SHA512/256 - Was not verifying correctly thought it was SHA224 and SHA256. This has been corrected.

TDES - Removed Keying Option 3 (K1=K2=K3) from the screens

TDES - Removed the Keying Option 3 Monte Carlo and MMT tests from the suite of tests for TDES.

RSA - Added Legacy tests to the TestInfo.txt file. They were not being printed on the cover letter.

RSA2 - Key Gen Screen. Make it clear that the Fixed/Random key selection on the first screen is for all methods except Appx B.3.3

RSA2 - Key Gen Screen. When 186-2 Key Generation was selected, was forcing either random or fixed public key in the 186-4 part of the screen to be selected. This is not required in 186-2 Key Generation - just erroneously required one option to be selected but never used. This has been corrected.

For any algorithm validation request where a lab has used CAVS 17.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 June 4, 2015.

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.5.

For new algorithm validations tested with CAVS17.5, please begin supplying the additional information concerning how and by whom the algorithm testing was performed. A new form is generated by the CAVS17.5 tool called the (foldername)TestingMethodInfo.txt. This page of information will be signed by the appropriate individuals depending on whom and where the testing was performed, will be scanned in as a pdf (like you currently do the official submission cover letter) and will be included in the cryptographic algorithm validation submission.

[02-05-15] --Â Change in TDES testing as of March 4, 2015Â --NIST SP 800-67 Revision 1, dated January 2012 states in Section 3.1:

A TDEA key ....A key bundle shall not consist of three identical keys.

Currently the TDES algorithm validation testing, as discussed in SP800-20, uses Keying Option 3 (where K1=K2=K3) when testing Keying Option 1 and Keying Option 2. This has been removed from the Monte Carlo and the MMT tests. The request files Monte1.req and MMT1.req (where K1=K2=K3) will no longer be generated by CAVS and therefore won't be used in the testing of TDES implementations. Monte2.req, Monte3.req, MMT2.req and MMT3.req will still be generated and used for testing.

Because the Keying Option 3 is used in the testing of CAVS, currently implementations need to have the ability to accept a key bundle consisting of three identical keys in addition to supporting Keying Option 1 and/or Keying Option 2.

Over the next 3 months (by June 2015), the CAVS testing will not allow TDES implementions to accept a key bundle consisting of three identical keys. Implementations supporting key bundles consisting of three identical keys will not pass the TDES cryptographic algorithm validation testing.(See 6/4/15 Announcement)

The CAVP will be updating the TDES testing in the CAVS tool in stages to phase out the use of Keying Option 3.

Phase 1 (In CAVS 17.5) (NOTE THESE DO NOT REQUIRE ANY CHANGE IN IMPLEMENTATION DESIGN):

Remove the radio button to select Keying Option 3

Modify the Monte Carlo and MMT validation tests to remove the use of Keying Option 3 (where K1=K2=K3) in the testing

Phase 2 (Within three months (June 2015)):

Add validation testing that will assure that the TDES implementation does not allow three identical keys to be used as input.

[01-23-15] -- Announced that the CAVP will be adding additional requirements to the vendor/implementation information page to record how and by whom the algorithm testing was performed for this IUT along with some additional testing details.Â This will replace the current requirements of this information in the CMVP Cryptik tool.