search

usnistgov / ACVP

Industry Working Group on Automated Cryptographic Algorithm Validation
https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program
172 stars 66 forks source link

KAS-ECC w 2-step KDF - issue with Sha2-224 #1067

Closed Seamusfish closed 3 years ago

Seamusfish commented 4 years ago

I have a customer attempting to generate responses for a KAS-ECC with two-step KDF (Static Unified, No key confirmation). They are getting a full pass on all tests except those using SHA2-224. The issue was duplicated using the same vector sets, but various crypto libraries. I have posted the meat of the question as written below, in case I would miss a detail re-typing it.

Test session is # 124377 Vector set in question is # 371111

"...We successfully matched for all vector sets except for those involving SHA2-224. In all cases it looked like we matched for the first 224 bits and then had a mismatch on the final 32 bits of each 256-bit output. This corresponds to incorrect outputs for iteration 2 of the HKDF. Reviewing the code I couldn't find any obvious issues that would lead to these mismatches. I then decided to utilize additional reference vectors in RFC6234 to validate that our implementation was indeed generating the expected outputs for SHA2-224 operation. When that matched I decided to use the open source reference implementation for RFC 6234 (https://github.com/Madricas/RFC-6234) on the ACVP input vectors and saw that it generated the exact same results as our implementation (meaning it also didn't match the ACVP reference vector outputs). In parallel with this effort, one of our engineers used a very popular Python open-source crypto primitive library (https://cryptography.io/en/latest) and saw the same results as for our implementation and that of RFC6234.

So, in light of this 3-1 mismatch, we'd like to pose a question to the ACVP team to see if there is indeed an issue with their implementation. If not, then perhaps they can provide some additional information (e.g., T[i] values for HKDF, and any other intermediate results they can provide) that would allow us to continue debugging things on our end."

Kritner commented 4 years ago

If you have a specific scenario you'd like to go through intermediate values for, let me know. In the meantime however, here is an example two step run's intermediate values with a configuration similar to what was in your vector set.

FYI
data = fixedInfo || counterBits
kTemp = PRF(kdfKey, data)

fixedInfo = 00000000000000000000000000000000
z = 00000000000000000000000000000000

Randomness extract / kdf key = 364CC197D413A907E5C014F7FBC35BCD9E4F0083E176FFF4DBDD5F7C

n = 2

    counterBits[0] = 01
    data[0] = 0000000000000000000000000000000001
    kTemp[0] = EB9436CDC0C6FBC168A3BDE32929C104C2E4F4C1DEA2CA3485A7799E

    counterBits[0] = 02
    data[1] = 0000000000000000000000000000000002
    kTemp[1] = 49870E0C869C714B31F39C9D70B7C29A92D3C6F355A5FC679E553428

fullKey =  EB9436CDC0C6FBC168A3BDE32929C104C2E4F4C1DEA2CA3485A7799E49870E0C869C714B31F39C9D70B7C29A92D3C6F355A5FC679E553428
truncated to l of 256 dkm = 
EB9436CDC0C6FBC168A3BDE32929C104C2E4F4C1DEA2CA3485A7799E49870E0C

You said that this was the only KDF MAC algo that you were not passing on, but you didn't specify your registration for the other algorithms. So just to clarify, were you hitting a second iteration through the internal KDF loop for the other registrations?

Seems the first iteration is correct, but the second incorrect. Hopefully we'll be able to see the difference in the above simplified case.

Seamusfish commented 3 years ago

Thank you for providing the intermediate values, this helped us clear up the issue.