OT: Anyone speak FIPS?

  • Last Post 21 September 2015
Ravi.Sabharanjak posted this 18 September 2015

Hello all,
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..

Order By: Standard | Newest | Votes
barkills posted this 18 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.


Good luck!





joe posted this 18 September 2015

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


Ravi.Sabharanjak posted this 19 September 2015

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


esf posted this 19 September 2015

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






SmitaCarneiro posted this 21 September 2015

If you use ECDSA you will definitely have issues with apps that use Java 6 or 7. Don’t know about 8.





Ravi.Sabharanjak posted this 21 September 2015

Thanks everyone. I will be turning tips compliance off on the HSMs.