KAS-ECC-SSC tests failing for go/crypto/elliptic module

[ksridhar57]

Hi,

I noticed that in the case of kas role as initiator, a few test cases were failing with the verdict shown as Z does not match. Also, the z value is variable as we generate keys with a random input. How does the server match the z value in such cases? Any pointers on why these specific tests failed would be very helpful in proceeding further.

These are the details of the tests -
vsId: 587668,
curve: P-521
KAS role: initiator
scheme: ephemeralUnified

These are the failed tests -
"tcId": 27,
"result": "failed",
"reason": "Z does not match"
},
{
"tcId": 28,
"result": "passed"
},
{
"tcId": 29,
"result": "failed",
"reason": "Z does not match"
},
{
"tcId": 30,
"result": "failed",
"reason": "Z does not match"
},
{
"tcId": 31,
"result": "passed"
},
{
"tcId": 32,
"result": "failed",
"reason": "Z does not match"
},
{
"tcId": 33,
"result": "passed"
},
{
"tcId": 34,
"result": "failed",
"reason": "Z does not match"
},

Thanks,
Krishna

[ksridhar57]

Hi,

Any inputs here would be very helpful.

I would also like to add that I'm running these test vectors against Go lang crypto library version 1.12.1. I would like to know if there is anything specific to SP800 56A R3 that needs to be handled.

Thanks!

[ksridhar57]

Hi,

We tried with new set of vectors and now we observe the following error -

{
“acvVersion”: “1.0"
},
{
“error”: “Responses for vsId 587758 not received by the server.”
}
]

Please let us know how we may proceed. Thanks!

[Kritner]

It appears that the IUT provided z values are not being padded properly as per Appendix C.2 in SP800-56Ar3:

Here is a repro of the calculation specified in the output section of C.2: https://replit.com/@Kritner/ExpectedBitLengthOfZ#main.py

The p / q value taken from:

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-186-draft.pdf

---

For the P-521 curve, the expected length of z will be 66 bytes or 528 bits.

using tcId 27 as an example, the IUT provided:

ab652f39036a344b2f135702e24d9173d1e95847628075a0d875680c115fb0885fbc0afc327b1e6df2c1922bc6cd7906101c92c114be61c92349c60626c38484a8 which is 130 hex characters, or 65 bytes, 1 byte less than expected.

The ACVP Server generated value for that same test id of 27 is:

00ab652f39036a344b2f135702e24d9173d1e95847628075a0d875680c115fb0885fbc0afc327b1e6df2c1922bc6cd7906101c92c114be61c92349c60626c38484a8.

I would imagine it'd be a similar situation with the other failing test cases from the vector set, but I did not check.

Additionally, there is a showExpected flag that can be used when POST/PUTing your answers that will give the "provided vs expected" results on a per test case basis. showExpected information can be found here: https://pages.nist.gov/ACVP/draft-fussell-acvp-spec.html#section-12.17.4

---

regarding your comment in #1196 (comment), I would need to know what endpoint you're trying to hit, the verb being used, and the payload.

[ksridhar57]

Hi,
This is how we upload our responses -

1. Run the following command with vsid info. The generated response is stored in the directory named with the vsid which the acvp proxy automatically picks up.
   ./acvp-proxy --vsid 588211

2. The end point we use is https://demo.acvts.nist.gov/

[ksridhar57]

testvector-response.txt

• changed the response file extension to .txt from .json in order to attach here.

[ksridhar57]

Sorry to bombard you with questions, here is another one. Is there a way we can limit the number of test cases we receive for a given vsid? For instance SHA tests have about 512 individual tests for Algorithm validations. Can that number be configured?

Appreciate your prompt responses and it really helps! Thanks very much.

[Kritner]

Hi,
This is how we upload our responses -

1. Run the following command with vsid info. The generated response is stored in the directory named with the vsid which the acvp proxy automatically picks up.
   ./acvp-proxy --vsid 588211
2. The end point we use is https://demo.acvts.nist.gov/

This is only the root URL that's being hit, not the actual endpoint - though looking through our code, the only time this response is returned is if you try to get "results" for a vector set, without having uploaded your responses.

The full endpoint that can return that response is:

/acvp/v1/testSessions/{{testSession_Id}}/vectorSets/{{vs_id}}/results

Regarding the ACVP Proxy command you're using, I can't really speak to that as it's not our product.

---

testvector-response.txt

• changed the response file extension to .txt from .json in order to attach here.

The file you attached is a response file from IUT to ACVP Server, but I don't see any indication of it having been uploaded to us, can you try again? Additionally knowing that datetime the upload was attempted so I can double check our logs.

---

Sorry to bombard you with questions, here is another one. Is there a way we can limit the number of test cases we receive for a given vsid? For instance SHA tests have about 512 individual tests for Algorithm validations. Can that number be configured?

Appreciate your prompt responses and it really helps! Thanks very much.

No there is no controlling from the client perspective how many test cases are generated for a vector set. the isSample flag MAY change the total number of test cases to a smaller amount, but not for all algorithms. The flag isSample is only available on demo.

---

Just to circle back to the issue at hand, did my response in #1196 (comment) make sense?

[ksridhar57]

about your comment in #1196, yes that helped.
I had a followup question on this regard. I'm testing against the standard go crypto library which provides the implementation for P521 under the go/crypto/elliptic package. As what I have read in a few materials online, the value of z can range from 64 bytes to 66 bytes (and very rarely less than 64 bytes) which is correct as go implements a minimum byte length representation. Explained here - https://stackoverflow.com/questions/50002149/why-p-521-public-key-x-y-some-time-is-65-bytes-some-time-is-66-bytes
Does it then mean that the test driver code needs to ensure that the resultant z value is padded before being verified with the acvp server?

[Kritner]

about your comment in #1196, yes that helped.
I had a followup question on this regard. I'm testing against the standard go crypto library which provides the implementation for P521 under the go/crypto/elliptic package. As what I have read in a few materials online, the value of z can range from 64 bytes to 66 bytes (and very rarely less than 64 bytes) which is correct as go implements a minimum byte length representation. Explained here - https://stackoverflow.com/questions/50002149/why-p-521-public-key-x-y-some-time-is-65-bytes-some-time-is-66-bytes
Does it then mean that the test driver code needs to ensure that the resultant z value is padded before being verified with the acvp server?

I'm not exactly sure what you mean by "test driver code" - if that's the harness or proxy sitting above the actual implementation, then probably not. The padding here is important for KAS-*-SSC, since SSC's intention is to be used in conjunction with a KAS-KDF to make up a "KAS validation". The KDFs (in I believe all instances?) perform one way functions (such as a hash) upon the shared secret, so it's quite important that the length of the output shared secret is appropriate, since hashing a shared secret z value of BE EF is very different than hashing 00 BE EF.

So this padding seems like it should be the responsibility of the implementation itself, rather than the test harness/proxy calling into the implementation. Either that or the KDF implementation would need to account for this "domain parameter dependent (in this case P-521)" padding, but since the KDF should be shared secret generation (and domain parameter) agnostic, it seems to make the most sense that the SSC implementation performs the padding.

[ksridhar57]

Hi, I had another question about the KAS component tests where I notice the error "IUT should detect issue in ACVP server ephemeral public key" for some tests. I did notice that you have shared some information for the exact same error - usnistgov/ACVP-Server#60

I would just like to ask this question - does the verification require to check both ephemeral public server key pair and public IUT key pair in VAL type tests to determine if they individually are points on the specified curve?

[Kritner]

It depends on the capabilities registered, and the revision of testing you're testing against. The best bet is to run all provided public keys through the partial and/or full validation process as a part of the routine regardless of whether or not we're actually testing against "bad values" IMO.