Summary: A HSM vendor - Gemalto / Safenet - is telling us that they have disabled the ability to generate RSA 4096 bit keys in their firmware for HSM's if it is in FIPS compliant mode as NIST has dropped it in their guidance.
I'm hoping that someone familiar with FIPS can confirm / clarify this for me. The vendor has sent me a link to FIPS 186-4 and "the 131a transition", that is beyond my understanding.
Because of this, I either have to bring up my PKI with a lower bit strength OR run the HSM in non-FIPS mode, neither of the choices are appealing to me. Another choice is to use ECDSA, but apparently I am likely to run into application compatibility issues..
OT: Anyone speak FIPS?
- 81 Views
- Last Post 21 September 2015
That looks like an accurate claim by the vendor. FIPS 186-4 says:
“This Standard specifies three choices for the length of the modulus (i.e., nlen): 1024, 2048 and 3072 bits. Federal Government entities shall generate digital
signatures using one or more of these choices.”
“Federal Government entities other than CAs should use only the first two choices (i.e., nlen = 1024 or 2048) during the timeframes indicated in SP 800-57. A
CA should use a modulus whose length nlen is equal to or greater than the moduli used by its subscribers. For example, if the subscribers are using nlen = 2048, then the CA should use nlen ≥ 2048. SP 800-57 provides further information about the selection
of the bit length of n. Possible exceptions to this rule include cross certification between CAs, certifying keys for purposes other than digital signatures and transitioning from one key size or algorithm to another.”
SP 800-57 (of which there are 3 revisions and a 4th rev in draft), has a section 5.6.1 covering “Comparable Algorithm Strengths” which is likely what
FIPS 186-4 was referencing. Table 2 in that section, and the accompanying explanation, reference FIPS 186, re-asserting that 3072 is the largest approved key size for finite-field cryptography, unless you take SP800-56A into account, and then the largest key
size approved is 2048.
The “131a transition” is a vague reference to SP 800-131a, covering the transition of crypto algorithms and key lengths. If my quick read of that one is accurate,
the end of 2013 is when many key lengths were deprecated and there’s another deprecation date at the end of 2015. Appendix A provides decision rationale, but doesn’t cover even larger key sizes in its discussion.
Nicely stated Brian!
My question would be why you really need to use 4096 bit keys for your root or CA certs. This isn't really a common practice with commercial CAs and 2048 keys are considered generally safe regardless. I agree that if you want to ensure compat you probably want to stick with RSA keys if you have concerns about compat with EC keys.
I guess just the thought that the pki would be a little future proof, given that the root ca validity is 20 years. Perhaps I can do 4k on the root and 2k on the issuing ca.
It is strange that NIST has (looks like explicitly) ruled out 4k bit strength. It seems that they could easily have said 3072 or greater..
…and if you care about this key strength, then by definition you don’t’ care about FIPS per the standard quoted. So either it’s fine to run in non-FIPS mode and
hence use these keys, or you need to move keys, but even asking for this in FIPS mode is logically inconsistent per the read of the standard below.
If you use ECDSA you will definitely have issues with apps that use Java 6 or 7. Don’t know about 8.
Thanks everyone. I will be turning tips compliance off on the HSMs.