KAS-ECC Fixed Info Construction for SP 800-56Ar3

[jbarnesweb]

Protocol Section
ACVP documenation
https://pages.nist.gov/ACVP/draft-hammett-acvp-kas-ecc-sp800-56ar3.html#name-fixedinfopatternconstructio

NIST Special Publication 800-56A Revision 3
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf

Protocol Question
Are there discrepancies in fixed info pattern construction between SP 800-56Ar3 and ACVP coverage? For example, r3 states that AlgorithmID is required for OneStep KDF. ACVP does not require it.

From section 5.8.2.1 One-step Key Derivation

"AlgorithmID: A required non-null subfield that indicates how the derived keying material
will be parsed and for which algorithm(s) the derived secret keying material will be used.
For example, AlgorithmID might indicate that bits 1-112 are to be used as a 112-bit
HMAC key and that bits 113-240 are to be used as a 128-bit AES key."

Follow up question 1

Given the test group below, is the correct fixed info bit string the following? (I added the concat symbols for clarity; they would not be used in the shared secret computation.)

60CDCBA8230F3B9C63FE37E68A06F726||123456ABCD||434156536964

Follow up question 2
For the C(0e, 2s) scheme, party U is required to generate a Nonce. Given the same algorithmId, partyU and partyV, is the dkmNonce concatenated as follows?

dkmNonce
96C0B308DA641336026C918A83E2893370CD6BEE1AB3E80036AD73CED499FA2A7A1349F78882BD498A288EC31CD3FFCC

60CDCBA8230F3B9C63FE37E68A06F726||123456ABCD||96C0B308DA641336026C918A83E2893370CD6BEE1AB3E80036AD73CED499FA2A7A1349F78882BD498A288EC31CD3FFCC||434156536964

The test session group with one test case.

    "revision": "Sp800-56Ar3",
    "testGroups": [
      {
        "domainParameterGenerationMode": "P-521",
        "iutId": "123456ABCD",
        "kasRole": "initiator",
        "kdfConfiguration": {
          "auxFunction": "SHA2-384",
          "fixedInfoEncoding": "concatenation",
          "fixedInfoPattern": "algorithmId||uPartyInfo||vPartyInfo",
          "kdfType": "oneStep"
        },
        "l": 256,
        "scheme": "ephemeralUnified",
        "serverId": "434156536964",
        "testType": "AFT",
        "tests": [
          {
            "ephemeralPublicServerX": "009FFB56EDBA11B36E99E1BBD4CCB1B71D53DC097959670C82DAD938DABFB4F9A767D1E238A3E940E183D12661C2AED5431E00358116E428EEE4F8B7002B716F6A6E",
            "ephemeralPublicServerY": "0180C4EA288D4A2E1D347A496047F3717A5697E4575EAE21EAF98C2B1F4F04853A7DFEC5BD1079AFC3ECCCD582812AEBC89C0B93F25817512B77852FA2841AF11838",
            "kdfParameter": {
              "algorithmId": "60CDCBA8230F3B9C63FE37E68A06F726",
              "kdfType": "oneStep"
            },
            "tcId": 1
          },

[Kritner]

Are there discrepancies in fixed info pattern construction between SP 800-56Ar3 and ACVP coverage? For example, r3 states that AlgorithmID is required for OneStep KDF. ACVP does not require it.

From section 5.8.2.1 One-step Key Derivation

"AlgorithmID: A required non-null subfield that indicates how the derived keying material
will be parsed and for which algorithm(s) the derived secret keying material will be used.
For example, AlgorithmID might indicate that bits 1-112 are to be used as a 112-bit
HMAC key and that bits 113-240 are to be used as a 128-bit AES key."

Honestly the SP is a bit frustrating when it comes to the fixed info construction, there's a fair amount of "SHALL"s mixed in with "SHOULD"s, "REQUIRED"s and "MAY"s.

To answer your specific question, we are not requiring the AlgorithmId for testing against ACVP, it MAY be registered as a part of fixed info construction, though we are using a random value for its place, rather than the built value described in the above snippet from the SP (that relied on uses of "MAY" in a "REQUIRED" field - part of the reason it's not being used as a required field in the ACVP testing). There is also an outstanding issue #1177 that will change a bit about some of the fields in fixed info construction, in that it will allow the specification of lengths to be used for some of fields.

---

Given the test group below, is the correct fixed info bit string the following? (I added the concat symbols for clarity; they would not be used in the shared secret computation.)

60CDCBA8230F3B9C63FE37E68A06F726||123456ABCD||434156536964

The above is missing the ephemeral data proceeding the serverId, the xPartyInfo is itself a concatenation of partyId||ephemeralData - in this case the ephemeral public key making up the ephemeralData portion. At a glance, the fixed info should be:

60CDCBA8230F3B9C63FE37E68A06F726||123456ABCD||434156536964||009FFB56EDBA11B36E99E1BBD4CCB1B71D53DC097959670C82DAD938DABFB4F9A767D1E238A3E940E183D12661C2AED5431E00358116E428EEE4F8B7002B716F6A6E||0180C4EA288D4A2E1D347A496047F3717A5697E4575EAE21EAF98C2B1F4F04853A7DFEC5BD1079AFC3ECCCD582812AEBC89C0B93F25817512B77852FA2841AF11838

where the two additionally concatenated bitstrings are the ephemeralPublicServerX and ephemeralPublicServerY from the provided test case.

---

Follow up question 2
For the C(0e, 2s) scheme, party U is required to generate a Nonce. Given the same algorithmId, partyU and partyV, is the dkmNonce concatenated as follows?

dkmNonce
96C0B308DA641336026C918A83E2893370CD6BEE1AB3E80036AD73CED499FA2A7A1349F78882BD498A288EC31CD3FFCC

60CDCBA8230F3B9C63FE37E68A06F726||123456ABCD||96C0B308DA641336026C918A83E2893370CD6BEE1AB3E80036AD73CED499FA2A7A1349F78882BD498A288EC31CD3FFCC||434156536964

Yes, but with the same issue as the previous section in that the ephemeral data from the other party should be included as the concatenated field of xPartyInfo -> xPartyId||xEphemeralData.

[jbarnesweb]

Just to clarify, my understanding is there is no ephemeral data in 0e, 2s. Should the concat use the static public key of party U?

[jbarnesweb]

One thing that has quite frustrating about the test development is that there is such a yuge amount of translating from the sp to the acvp nomenclature.

The sp uses C(xe, xs) to describe the schemes, and it seems to me to be the right level of abstraction.

The sp rarely, if ever, uses the words "initiator" or "responder" to describe the roles, where ACVP uses partyU and partyV rarely (only in the fixed info pattern).

Final rant: the ACVP uses server and iut when it should say partyU and partyV. The SP is more clear than the ACVP.

My hope is that with acvVersion 2.0, the ACVP will map more closely to the sp.

[Kritner]

Just to clarify, my understanding is there is no ephemeral data in 0e, 2s. Should the concat use the static public key of party U?

Sorry, given the above test case with the provided ephemeral information, I did not realize this was a hypothetical question using the vector as a base, and missed the mention about it being a static scheme. But no, the static information is not used as ephemeral data for the KDF, in this case the "dkmNonce" that's generated/provided is the ephemeral data used.

One thing that has quite frustrating about the test development is that there is such a yuge amount of translating from the sp to the acvp nomenclature.

The sp uses C(xe, xs) to describe the schemes, and it seems to me to be the right level of abstraction.

The sp rarely, if ever, uses the words "initiator" or "responder" to describe the roles, where ACVP uses partyU and partyV rarely (only in the fixed info pattern).

Final rant: the ACVP uses server and iut when it should say partyU and partyV. The SP is more clear than the ACVP.

Agreed the C(xe, xs) is used throughout the document, though I feel like the scheme name is as well, no? Same thing with the initiator and responder language - most of this is from the translation that occurred from CAVS to the new system. It would have probably made sense to reevaluate terminology used at that point, but with KAS being as big as it is, trying to get more or less 1:1 mapping from CAVS -> ACVP was the first and foremost goal.

FWIW in case you've not seen CAVS, the previous tool for crypto validations:

That's where a lot of this came from, and I assumed (perhaps incorrectly) that it was more the standard nomenclature for things.

All of the scheme names should match the SP, though as you mentioned it's probably easier to understand more about the scheme by referring to it by its C(xe, xs) values. PartyU and PartyV are definitely used more heavily in the SP now, the same consideration probably should have happened when doing the original conversion here as well.

We can keep all of this in mind for the next iteration for sure (perhaps do a poll?), and hopefully making that change from "initiator -> partyU" and "dhStatic -> C(0e, 2s)" won't be as jarring considering the difference in "what currently is".

[Kritner]

I don't think there was anything outstanding on this issue, but feel free to reopen/update if there was.

[jbarnesweb]

Thanks for the explanation.