search

usnistgov / ACVP-Server

A repository tracking releases of NIST's ACVP server. See www.github.com/usnistgov/ACVP for the protocol.
58 stars 20 forks source link

SP 800-56C KAS-KDF Feature Request #136

Open powersmc opened 3 years ago

powersmc commented 3 years ago

environment Both

testSessionId N/A

vsId N/A

Algorithm registration { "algorithm":"KAS-KDF", "revision":"Sp800-56Cr1", "mode":"OneStep", "auxFunctions":[ { "auxFunctionName":"SHA2-256", "macSaltMethods":[ "default" ] } ], "fixedInfoPattern":"literal[20]", "encoding":[ "concatenation" ], "l":256, "z":[ {"min": 224, "max": 512, "increment": 8} ] },

Endpoint in which the error is experienced /testSessions POST

Expected behavior In general, the SP 800-56C and SP 800-56A/B standards are pretty flexible on what is allowable for the FixedInfo field, with broad statements like: "Recommended formats for FixedInfo when used by a one-step key-derivation method are specified in Sections 5.8.2.1.1 and 5.8.2.1.2. One of those two formats should be used by a one-step key-derivation method specified in SP 800-56C when the auxiliary function employed is H = hash"

While there are some specific requirements imposed if concatenation or ASN.1 are used, there's no hard requirement that you must use one of those two formats. We are running into issues now where vendors have defined custom formats, where it would be beneficial if the ACVP server would allow for arbitrary FixedInfo to be specified. For example, perhaps having an option for encoding that's just "custom" where the IUT is then allowed the flexibility to: -Not specify anything under "fixedInfoPattern" -The server-side would not provide any fixedInfo inputs in the request files -The IUT would include the full contents of the fixedInfo field (hex encoded) in the individual tcId responses

Additional context We have encountered a few scenarios where a vendor defines custom formatting for fixedInfo where they're otherwise rendered unable to test their 56C KDFs as a result.

livebe01 commented 3 years ago

Hi @powersmc, thanks for sharing this with us. I just took a look at the 56* specs and what you're describing seems reasonable and looks like something we should be able to do.

Just to confirm - you're speaking specifically about OneStep?

powersmc commented 3 years ago

Yes, that's correct. This request was only intended for the OneStep KDF

livebe01 commented 3 years ago

Perfect. We can't pick this up at the moment, but we'll make sure this gets added in a future release.

powersmc commented 3 years ago

Hey, just checking if there has been any progress on this request. I've seen a few 56C related updates get pushed over the past month or so, but none seemed to be directly related to this.

livebe01 commented 3 years ago

No, I don't believe so. Recently we've been working on one larger feature addition to ACVTS, on adding a new algorithm that's quite hairy to implement testing for, and some internal code reorganization and associated build/release changes. Apart from that, we've been focusing on bug fixes. Is this request time sensitive? If so, can you send an email to @celic?

livebe01 commented 1 year ago

@powersmc fyi, we've worked on, but haven't as of yet been able to come full circle on baking this into ACVTS. If you do have outstanding testing related this ticket, please let me know so that we can discuss how it can be addressed in the interim.