Join Log in
Score:3
avatar Crypto

Are non-FIPS algorithms allowed to execute at all in a FIPS-compliant system?

cn flag
Adam Ierymenko

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

504
2 + 0
Score:4
poncho avatar Crypto
my flag
poncho

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.

0 + 2
cn flag
Adam Ierymenko
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.
1
Reply
poncho avatar
my flag
poncho
@AdamIerymenko: that is correct, and NIST is looking to approve constructions just as $\operatorname{SHA384}( K_0 \mathbin\| K_1 )$
0
Reply
Score:1
Swashbuckler avatar Crypto
mc flag
Swashbuckler

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.

0 + 4
cn flag
Adam Ierymenko
"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?
0
Reply
Swashbuckler avatar
mc flag
Swashbuckler
@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.
0
Reply
Swashbuckler avatar
mc flag
Swashbuckler
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.
0
Reply
cn flag
Adam Ierymenko
Actually see [section 8.2 here](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf). "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.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.