3
$\begingroup$

If a piece of software is running in FIPS mode and using FIPS-certified cryptographic modules, is it permitted to execute any non-FIPS algorithms even if the security of the system is not uniquely dependent on them?

Example: lets say you have a system that exchanges two ECDH key pairs: one curve25519 key pair and one NIST P-384 key pair. Key agreement is performed using both key pairs and then the resulting secrets are concatenated and hashed with SHA-384.

Cryptographically I don't see a problem since the result of SHA-384(K0 | K1) is as strong as the strongest curve. This is because SHA-384(a secret | a known value) is a secret, meaning that if an attacker cracked say curve25519 they would still not know the result of that secret hashed with another secret they don't know.

My question is whether FIPS allows this, or whether it must execute only FIPS-certified code and algorithms. Could you consider the curve25519 computed shared secret a "salt" or something?

Edit: consider that the result of the non-FIPS agreement with e.g. Curve25519 could be mixed with the "official" secret as a salt e.g. HMAC-SHA384(salt, key).

Improve this question
$\endgroup$

2 Answers 2

Reset to default
1
+100
$\begingroup$

When you say FIPS in this context I assume you mean FIPS 140, if that's correct, then there are limited situations where you can use non-FIPS approved algorithms and still be FIPS compliant.

Take a look at the Implementation Guide, there's a section "Example scenarios of non-approved cryptographic algorithms allowed in FIPS mode". I don't think your example meets any of the three scenarios outlined in the document.

Improve this answer
$\endgroup$
4
  • $\begingroup$ "Use of an approved, non-approved or proprietary algorithm for a purpose that is not security relevant or is redundant to an approved cryptographic algorithm" ? What If the result of an extraneous key exchange is considered supplemental or a "salt" in a key-derivation function? $\endgroup$
    – Adam Ierymenko
    Commented Jul 15, 2021 at 18:37
  • $\begingroup$ @AdamIerymenko I'm not familiar with all of the NIST directives for such algorithms, but my guess is that it won't be FIPS compliant. For something like PBKDF2, the salt is supposed to be from a FIPS approved RNG, so definitely not compliant in that case. You'd have to read the NIST doc for the specific KDF you're interested in and see what it says. $\endgroup$
    – Swashbuckler
    Commented Jul 16, 2021 at 20:27
  • $\begingroup$ Anything that's supplemental, but still security related is unlikely to be FIPS compliant. The philosophy is that anything that isn't FIPS compliant is plain text, so if you consider that supplement as plain text and it's still secure then it's probably ok. $\endgroup$
    – Swashbuckler
    Commented Jul 16, 2021 at 20:30
  • $\begingroup$ Actually see section 8.2 here. "This Recommendation does not require the use of a randomly selected salt value. In particular, if there are no means to select a salt value and share it with all of the participants during a key-establishment transaction, then this Recommendation specifies that a predetermined default (e.g., all-zero) byte string be used as the salt value." It may be okay for HMAC(salt, key) where the C25519 ECDH shared secret (or a hash of it) is used as the salt. Will ask around. $\endgroup$
    – Adam Ierymenko
    Commented Jul 28, 2021 at 15:57
4
$\begingroup$

Actually, curve25519 is well on its way to FIPS approval (NIST SP 800-186), but that's not what you're asking about.

To answer your question, yes, NIST has stated that they do allow non-approved algorithm in parallel with their favored key exchange. At the moment, their official approved process would require processing the nonapproved key share differently from the approved one; however they note that this will change in the next version of NIST SP 800-56C.

Their actual statement (from https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs) which is applicable to more than just postquantum cryptography (some text which gave postquantum examples were elided):

Is it possible for a hybrid key-establishment mode to be performed in a FIPS 140 approved mode of operation? (added 1/28/20)

A hybrid key establishment mode ... is defined here to be a key-establishment scheme that is a combination of two or more components that are themselves cryptographic key-establishment schemes. The desired property is that keys derived by a hybrid key-establishment scheme remain secure if at least one of the component schemes is secure...

Current NIST standards ... can accommodate several hybrid key establishment constructions in “FIPS mode,” as defined in FIPS 140. For example, assume that the value Z is a shared secret that was generated within a NIST-approved cryptographic scheme, and that a value T is generated or distributed through other scheme(s)... The following are the different ways to incorporate the value T in the key derivation procedure to achieve a hybrid mode which is permitted by current standards:

For any one-step key derivation method that is specified in SP 800-56C, an input defined as SuppPrivInfo can be included in an (optional) FixedInfo field, and T may be included in that field. In any of the key derivation methods specified in SP 800-56C, whether one-step or extraction-then-expansion, the value T may be included in the salt field. Additionally, NIST plans to incorporate a cleaner, and therefore preferable, hybrid key establishment construction in a future revision of SP 800-56C:

In any of the key derivation methods specified in SP 800 - 56C, the revision would permit a concatenation of Z and T, e.g., Z||T, to serve as the shared secret instead of Z. This would require the insertion of T into the coding for the scheme and the FIPS 140 validation code may need to be modified.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ Sounds like the answer is probably yes, then, as long as the derivation of the final key is done in compliance with what they want and using a FIPS-compliant hash/KDF. $\endgroup$
    – Adam Ierymenko
    Commented Jul 13, 2021 at 20:50
  • $\begingroup$ @AdamIerymenko: that is correct, and NIST is looking to approve constructions just as $\operatorname{SHA384}( K_0 \mathbin\| K_1 )$ $\endgroup$
    – poncho
    Commented Jul 13, 2021 at 21:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.