Conversation
|
|
||
| * XECDH / keyGen / RFC7748 "AFT" - Algorithm Functional Test. The IUT is *REQUIRED* for each test case provided, to generate a key pair based on a curve. This information is then communicated to the ACVP server and validated. | ||
|
|
||
| * XECDH / keyVer / RFC7748 "AFT" - Algorithm Functional Test. The ACVP server is *REQUIRED* to generate a series of public keys based on the IUT provided curve(s). The public keys generated by the server *MAY* or *MAY NOT* be valid, the IUT is *REQUIRED* to determine if the public keys provided in the test cases are valid or invalid keys as they relate to the curve. |
There was a problem hiding this comment.
"... relate to the curve" - is it only to the curve or also to the assurance requirement of SP800-56A r3?
There was a problem hiding this comment.
@smuellerDD currently SP 800-56Ar3 is not considered since this algorithm is based on RFC7748
There was a problem hiding this comment.
In fact, Curve25519 and Curve448 don't really have invalid keys, as long as the number of bytes is correct (32 and 48, respectively)
|
|
||
| The following XECDH algorithms *MAY* be advertised by the ACVP compliant cryptographic module: | ||
|
|
||
| * XECDH / keyGen / RFC7748 |
There was a problem hiding this comment.
Just for the sake of clarity: SP800-186 defines the use of the Weierstraß representation of the curves 25519 and 448 as well to be used for ECDH. Do you deliberately want to disregard it or perhaps consider it being added at a later time?
There was a problem hiding this comment.
It's an interesting idea for future work, but since that was not part of RFC7748, it was omitted for now.
| |=== | ||
| | JSON Value | Description | JSON type | Valid Values | ||
|
|
||
| | curve | The curve names supported for the IUT in SSC | array | Any non-empty subset of {"Curve25519", "Curve448"} |
There was a problem hiding this comment.
https://github.com/usnistgov/ACVP/blob/master/src/kas/sp800-56ar3/ssc/ecc/sections/05-capabilities.adoc contains the hashFunctionZ keyword as well. Shouldn't this be considered here too to be in line with the already defined protocol?
There was a problem hiding this comment.
@celic I would be interested to hear your opinion on whether or not there should be an option to provide a hashed Z value here?
There was a problem hiding this comment.
Ah ok. This is to get around certain module requirements where it is unable to output Z, but can output a hashed Z. This would be reasonable to include to match KAS-ECC-SSC testing. It could be done now or at a later time.
I don't recall hearing people ask for the hashed Z capability on KAS-ECC-SSC but it was not an algorithm that I worked on personally. I can pull some data on validations and see how often it is used. If @smuellerDD is asking for it, likely he uses it at least.
There was a problem hiding this comment.
hashedZ gets used in about 30% of validations for KAS-ECC-SSC. That seems worth including.
There was a problem hiding this comment.
@celic okay, I personally don't understand why people use hashedZ, but I can add it as an option to the PR. It might take a few days.
|
|
||
| | tgId | The test group identifier | integer | ||
| | curve | The curve type used for the test vectors | string | ||
| | testType | The testType for the group | string |
There was a problem hiding this comment.
As mentioned above, https://github.com/usnistgov/ACVP/blob/master/src/kas/sp800-56ar3/ssc/ecc/sections/06-test-vectors.adoc defines the hashFunctionZ here.
|
|
||
| | tcId | The test case identifier | integer | ||
| | publicIut | The (little-endian encoded) IUT's XECDH public key | hex | ||
| | z | The shared secret Z | hex |
There was a problem hiding this comment.
https://github.com/usnistgov/ACVP/blob/master/src/kas/sp800-56ar3/ssc/ecc/sections/07-responses.adoc allows the returning of hashZ as an option.
3 participants
It seems like "Test Coverage" is still TBD...