The draft for FIPS 186-3 has been made available for public comment by NIST. (I actually expected this to happen a couple of months ago, given what I had heard and the fact that elements of FIPS 186-3 were referred to a bit in drafts of SP800-56 and SP800-57 from many months ago.)
FIPS 186, first published in 1994, specifies a digital signature algorithm (DSA) to generate and verify digital signatures. Later revisions (FIPS 186-1 and FIPS 186-2, adopted in 1998 and 1999, respectively) adopt two additional algorithms specified in American National Standards (ANS) X9.31 (Digital Signatures Using Reversible Public Key Cryptography for the Financial Services Industry (rDSA)), and X9.62 (The Elliptic Curve Digital Signature Algorithm (ECDSA)).
The original DSA algorithm, as specified in FIPS 186, 186-1 and 186-2, allows key sizes of 512 to 1024 bits. With advances in technology, it is prudent to consider larger key sizes. Draft FIPS 186-3 allows the use of 1024, 2048 and 3072-bit keys. Other requirements have also been added concerning the use of ANS X9.31 and ANS X9.62. In addition, the use of the RSA algorithm as specified in Public Key Cryptography Standard (PKCS) 1 (RSA Cryptography Standard) is allowed.
Prior to the submission of this proposed standard to the Secretary of Commerce for review and approval, it is essential that consideration is given to the needs and views of the public, users, the information technology industry, and Federal, State and local government organizations. The purpose of this notice is to solicit such views.
DATES: Comments must be received on or before June 12, 2006.
This draft can be found here. I quickly flipped through a little of the proposed standard and noted a few of the obvious changes.
- Most apparent and interesting given the history, RSA (PKCS#1) for digital signatures is formally included in this FIPS. RSA digital signatures have been allowed through guidance for quite some years now, but there was no formal NIST standard specifying what was allowed in the arena of RSA digital signatures. This version of FIPS 186 finally fixes that.
Other notes, RSA (PKCS#1) and rDSA (ANSI X9.31) are restricted to key sizes of 1024 bits, 2048 bits, and 3072 bits. The key generation must follow the requirements in Appendix B.3.1 of FIPS 186-3, where the technique for key generation is explicitly defined along with a large set of checks to be performed during key generation. This makes a big difference, as, prior to this specification, there were really no strong guidelines on RSA key generation for use by the Federal government (and everyone else that follows these standards).
- With the SHA-2 family now available, the big change for DSA itself is the addition of various key sizes greater than 1024 bits – 2048 bits (with SHA-244 or SHA-256) and 3072 bits (with SHA-256) – and the removal of key sizes less than 1024 bits, which had already become commonplace through guidance.
- (The key sizes make sense based on the guidelines for key strength, which state that keys with an effective strength of 128 bits, which 3072 bit RSA/DSA and 256 bit ECDSA are, will be appropriate well into the future (potentially beyond 2030). Only ECDSA has key sizes specified that go beyond 128 bits of effective strength.)
- Random number generators are no longer specified in the standard. Only random number generators specified for draft SP800-90 are to be used, and the strength of random number generators is finally becoming a criteria for usage. (SP800-90 is clearly becoming the official specification of random number generators.)
- The generation of primes, parameters, and key pairs has been updated quite a bit, and there are a variety of checks and verifications for assuring the correctness of these values now incorporated into the standard. This ties in with the various assurance elements that have been brought into the standard.
- There is a lot more process described in FIPS 186-3 than prior versions, which muddies the algorithm specification a bit. For example, there is discussion around assuring a key pair is tied to/possessed by the appropriate entity – I almost expected to find an appendix describing a full blown PKI that MAY be implemented.
Much of this points to a separate document, draft SP800-89, which is where I think all of it should go.
I can only imagine the new generation mechanisms, including domain parameters and random numbers, and the new key (and hash) sizes will tier out through the standards community quite rapidly and then out to designs/implementations.
In general, the coverage provided by various FIPS combined with various SPs is indicating a more robust and rigorous CMVP is taking hold. This is good news, as this guidance is now available to, and followed by, many people throughout the world.
(Please note the “Common Questions” post.)
Update: I have been asked a bunch of questions that I translated into the following list.
- When will this become a law? Will there be a transition period? What will be the impact to my DSA, RSA, ECDSA implementation?
- What will this mean to FIPS 140 validations where digital signatures are involved? Will it effect products already validated? Will it effect validation efforts in process? How will it effect future validation efforts?
- Does this impact algorithm testing efforts?
- You mentioned additional rigor in the CMVP – is that really true? Are FIPS 140-2 validation becoming more intensive? Will a FIPS 140-3 validation be more effort than a FIPS 140-2 validation?
- Speaking of FIPS 140-3, any news on this front? If it is coming down the pipe soon, should I hold off FIPS 140 validation until it is ready, or should I do the opposite and avoid the kinks/rigor of FIPS 140-3?
Unfortunately, these questions are not appropriate for D-kriptik to answer, but I thought it would be useful to at least publish the questions.
Update: I love people sharing information. You asked, and the comments section now has answers. Thanks to Ray Potter for responding.
Here’s my take on the questions above:
1. When will this become a law? Will there be a transition period? What will be the impact to my DSA, RSA, ECDSA implementation?
This will become effective after NIST has finalized the draft and completed additional due diligence through cryptanalysis. There will likely be a transition period (just as there was one for the withdrawal of DES). Modules with existing 186-2 implementations will not be affected; their FIPS 140-1 or 140-2 certificates will remain valid. It will mean that product vendors will need to incorporate the new implementation via custom coding or incorporation of a crypto lib.
2. What will this mean to FIPS 140 validations where digital signatures are involved? Will it effect products already validated? Will it effect validation efforts in process? How will it effect future validation efforts?
It won’t affect currently validated modules. Depending on the transition/implementation timelines, it may affect those in process. Watch the NIST CMVP site for details on transition periods.
3. Does this impact algorithm testing efforts?
NIST CMVP will likely require algorithm testing through the CAVP to verify conformance. As the standard is finalized, NIST will provide this guidance.
4. You mentioned additional rigor in the CMVP – is that really true? Are FIPS 140-2 validation becoming more intensive? Will a FIPS 140-3 validation be more effort than a FIPS 140-2 validation?
As FIPS 140-2 has evolved through implementation guidance, one could make the argument that validations have become more rigorous. One could also make the argument that FIPS 140-2 validations have become cleaner and less subjective because of the increase in guidance and precedence. YMMV
5. Speaking of FIPS 140-3, any news on this front? If it is coming down the pipe soon, should I hold off FIPS 140 validation until it is ready, or should I do the opposite and avoid the kinks/rigor of FIPS 140-3?
Contact the CMVP. There are many rumors floating around, and it’s best to take guidance from either an accredited lab or (preferably) from NIST CMVP directly. Whether you should validate under 140-2 now or wait for 140-3 comes down to basic principles of customer demand and business case. Every situation is unique. Do your due diligence. That’s essentially how I advise my clients anyway (of course, with much more detail and formal evaluation and strategic plans, but this is no place to advertise). If I were still running the program at Cisco, I know what I would do…
Andrew, feel free to correct me or add other insights…
[...] commented on an early draft here and mentioned a later draft [...]