-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KAS-ECC-SSC vs KAS-ECC/CDH-component #1187
Comments
Hi @davyrouillard, I was just taking a look at the 140-3 IG and the ACVP specs you referenced. FIPS 140-3 IG D.F Scenario 2, #2 includes this - "When path (2) is chosen, the CAVP testing may be performed either end-to-end, in which case the vendor is If I'm understanding everything correctly, the "KAS SSC testing" KAS-ECC-SSC / null / Sp800-56Ar3 is (i) and "full KAS testing" KAS-ECC/CDH Component/ Sp800-56Ar3 is (iii). The IG 2.4.B Resolution #5 explains that the key confirmation is considered a CVL and IG 2.4.B Additional Comment #1 explains why KAS-SCC is considered and algorithm vs a compontent. |
Thanks you @livebe01 for you answer. The examples of test vectors and results for KAS-ECC/CDH Component/ Sp800-56Ar3 shows that the aim of the test is to compute the shared secret z. If it was for key confirmation, I suppose we will see some MacTag value in the tests. I conclude that it is not for (iii). |
Sorry, I have closed the point by mistake but the question is always open for me. |
The CDH Component testing isn't for a specific KAS scheme, and was intended more as a "component test" utilizing the diffie hellman primitive. The specific components that were being tested I don't recall, but I don't know that it actually matters either? There is a fair amount of overlap in one of the KAS schemes (I want to say dhStatic?) to be sure, but the KAS schemes additionally MAY inject errors into some test types that the CDH component testing does not. Additionally the CDH component testing doesn't have separate notions of testing as the "initiator" and/or "responder" that the KAS based testing has. CDH testing, AFAIK, can pretty safely be considered separate from a KAS certification/validation. KAS certification/validation can be achieved through either path:
|
Hi @davyrouillard, I’ve been trying to get a good answer as to the purpose of "full KAS testing" KAS-ECC/CDH Component/ Sp800-56Ar3, but don’t have one as of yet. It’s possible that it could be related to PIV card testing. It is not the key confirmation CVL referenced in the 140-3 IG (which has not been implemented to date). Bottom line, if you only want to test SSC and obtain a KAS-SSC, you’ll want to use "KAS SSC testing" KAS-ECC-SSC / null / Sp800-56Ar3. |
Protocol Section
https://pages.nist.gov/ACVP/draft-hammett-acvp-kas-ssc-ecc.html
https://pages.nist.gov/ACVP/draft-hammett-acvp-kas-ecc-sp800-56ar3.html#name-ecc-cdh-component-test
Protocol Question
What is the difference between the" full KAS testing" KAS-ECC/CDH Component/ Sp800-56Ar3 and the "KAS SSC testing" KAS-ECC-SSC / null / Sp800-56Ar3 ? Both seem to test the Z computation but the implementation guidance 2.4B for FIPS-140v3 does not mention that the SSC may be viewed as a component.
The text was updated successfully, but these errors were encountered: