X9.63 KDF with SHA-1

[jvdsn]

Protocol Section https://github.com/usnistgov/ACVP/blob/master/src/ans9.63/sections/05-capabilities.adoc

Protocol Question Why does the X9.63 KDF only support SHA-224, SHA-256, SHA-384, and SHA-512? According to SP 800-135r1, all hash functions specified in FIPS 180-3 are approved. This would include SHA-1.

[livebe01]

Agreed. Thanks. We'll fix this.

[livebe01]

As a side note, we (NIST/CMVP/CAVP) are encouraging vendors to move away from SHA-1 and are planning for a transition away from SHA-1. See https://csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps

[livebe01]

Hi @jvdsn, @celic tracked this down. It looks like the reason we didn't implement SHA-1 for the KDF is that section 5.6.2 of ANSI X9.63-2011 requires "An Approved hash function that offers 112 bits of security or more shall be used, i.e. an Approved hash function whose output is 224 bits or more."

[jvdsn]

Hi @jvdsn, @celic tracked this down. It looks like the reason we didn't implement SHA-1 for the KDF is that section 5.6.2 of ANSI X9.63-2011 requires "An Approved hash function that offers 112 bits of security or more shall be used, i.e. an Approved hash function whose output is 224 bits or more."

Hi @livebe01 could you check ANSI X9.63-2001? SP 800-135r1 specifically references the 2001 version of the standard, not the 2011 version.

[livebe01]

I can. Do you have a client that wants their X9.63 KDF tested w/ SHA-1?

[jvdsn]

Yes, I have. Specifically, it's OpenSSL 3 which implements the X9.63 KDF with a variety of hash functions, including SHA-1: https://www.openssl.org/docs/man3.0/man7/EVP_KDF-X963.html. Apart from SHA-1, it also seems to support the truncated SHA-512 hashes and SHA-3.

What's interesting is that ACVP supports pretty much every hash for the X9.42 KDF (https://github.com/usnistgov/ACVP/blob/master/src/ans9.42/sections/05-capabilities.adoc), but only a specific subset for the X9.63 KDF (https://github.com/usnistgov/ACVP/blob/master/src/ans9.63/sections/05-capabilities.adoc). Do you know why there is a difference there? I would expect them to be consistent.

[celic]

This would be because of when x9.63 KDF was introduced by the CAVP. The x9.63 KDF was in CAVS originally which matched the definition provided in x9.63-2011. When we implemented CAVS algorithms in ACVTS, we copied the allowed parameters as well. The x9.42 KDF was not in CAVS (the algorithm was a functional duplicate of the TPM KDF I believe). It was introduced by the CAVP in ACVTS, and because it was "new", it made sense to support all reasonable hash algorithms.

I would agree that the truncated SHAs and SHA-3 would make sense to add to the x9.63 KDF. I would not be inclined to add SHA-1.

[jvdsn]

Hi @celic it would certainly be useful to add the truncated SHAs and SHA-3 to the X9.63 KDF as well. What is the reasoning behind not adding SHA-1?

[celic]

Because the x9.63 KDF standard our testing is based on does not allow SHA-1.

[jvdsn]

Because the x9.63 KDF standard our testing is based on does not allow SHA-1.

Well, the 2001 version of the standard (the one referenced in SP 800-135) does in fact allow SHA-1. A quote from Section 5.6.2:

Any ANSI-approved hash function that offers 80 bits of security or more may be used, i.e. any ANSI-approved hash function whose output is 160 bits or more. Possibilities, therefore, include the hash function SHA-1 which is specified in [3].

[celic]

I took a deeper read at x9.63-2001. It says that you'd only be allowed to use SHA-1 to generate 80-bit symmetric keys (see Table H-3). The requirement of 112-bits of security strength would likely take precedence here. I think there is no current practical use for x9.63 KDF with SHA-1 within FIPS 140.

[livebe01]

The fix for this is on Demo in release v1.1.0.28.

[livebe01]

The fix for this is on Prod in release v1.1.0.28.