SP800-56Cr1 KAS KDF doesn't allow fixed sized "partyId" or "algorithmId" although the standard doesn't prohibit using fixed sizes

[EdSmith-Viasat]

The SP800-56Cr1/2 standard seems to allow for fixed sized "partyId" and "algorithmId". It seems fixed sized "partyId" and "algorithmId" would be typical for most implementations.

Please clarify if we need to modify our implementation or if the ACVP server and the definition of the JSON request and response files needs to be undated to allow for fixed sized "partyId" and "algorithmId".

[Kritner]

@EdSmith-Viasat I don't really understand what's being asked here... partyIds are randomly provided in the vector set to be plugged in as a portion of your fixed info construction for the KDF, and algorithmIds are only provided if the fixed info pattern specifies they can be used.

We test the KDF implementation by requiring the inclusion of uPartyInfo and vPartyInfo which are composed of partyId||ephemeralData in order to assess the IUTs construction of the fixed info.

We're not making any claims as to if the partyId or algorithmId are or are not a fixed size, just that the IUT can properly form the fixed info, our testing is just occurring with the arbitrary 128 bits.

[EdSmith-Viasat]

@Kritner Our implementation of the One-Step KDF takes as input a 5 byte Algorithm ID, a 16 byte PartyU ID, and a 16 byte PartyV ID. We believe our implementation using fixed length values to create the "FixedInfo" field meets the requirements in SP 800-56C, in Section 5.8.2.1 of SP 800-56A, and in Section 5.5.2.1 of SP 800-56B.

Is there any way to get test vectors to test our implementation?

[GlennUL]

@Kritner Is there any possibility that custom fields could be implemented to meet vendor needs like this? Something to allow a selection of sizes for the different ID's.

[Kritner]

@GlennUL this is possible yes - though KAS has a lot of moving parts, and I'm currently otherwise heavily occupied in other work. I can try to take a look into getting this done over the next week or two, but I can't really promise anything; and it will need to go through the normal release cycle which will take a bit more time.

I haven't fully thought this through yet, but my current thinking about how to accomplish this change, and keeping it an optional set of capabilities, would be to add a few new properties to the KDF portion of the registration.

The current fixedInfoPattern can be registered like (snip):

{
  "fixedInfoPattern": "algorithmId||uPartyInfo||vPartyInfo"
}

on a similar "nesting" to the above property, as to not change the object type, perhaps something like this could be done:

{
  "fixedInfoPattern": "algorithmId||uPartyInfo||vPartyInfo",
  "fixedInfoConstraints": {
    "partyIdLength": 128,
    "algorithmIdLength": 40,
  }
}

The constraints would take in any other properties that don't currently have a "length" tied to them (like label, context). This fixedInfoConstraints will not impact the "ephemeralParty" data that is part of xPartyInfo as that is a concatenation of partyId and ephemeralData - ephemeral data always being a length associated with the domain parameters chosen for the scheme.

The change described above is only my current intention on how to go about it, feel free to provide feedback (you or others that is).

The change will most likely impact:

KAS-ECC / null / Sp800-56Ar3
KAS-FFC / null / Sp800-56Ar3
KAS-IFC / null / Sp800-56Br2
KAS-KDF / OneStep / Sp800-56Cr1
KAS-KDF / OneStep / Sp800-56Cr2
KAS-KDF / TwoStep / Sp800-56Cr1
KAS-KDF / TwoStep / Sp800-56Cr2
KAS-KDF / HKDF / Sp800-56Cr1
KAS-KDF / HKDF / Sp800-56Cr2

[Kritner]

I unfortunately will not have the bandwidth to get to this at the moment, but if this is something that is preventing a validation, please feel free to have the lab you're working with contact @celic through email at [email protected]