Single failing test case in KAS-FFC-SSC

[abkarcher]

environment Demo

testSessionId 247486 247488

vsId 981633 (tcId: 32) 981638 (tcId: 45)

Hello,

I am failing a single tc per test session running KAS-FFC-SSC. They don't seem to be tied to a particular group or test type, so I am at a bit of a loss. I know in the past there have been on very rare occasion bad cached values, wondering if something like that may have happened here. If not, might anyone have insight into the tcIds I am failing in my harness? Maybe its some sort of edge case. Thanks for your time!

Andrew

[livebe01]

Hi Andrew,

I haven't worked with this algorithm before and need to read up on it, but to get you something to work with sooner than later...

For tcId: 32, an AFT, it looks like you're passing a 4088 bit Z value, whereas we're expecting to receive a 4096 bit value. I suspect that if you were to prepend that 4088 bit Z value with a byte of 0s, that this case would pass. For these SSC tests, you will need to pad your Z values with 0's on the most significant side of the value to ensure that it's the proper length, i.e., 4096 bits.

tcId: 45 is a VAL test. The error we provide for this test is, "Incorrect TestPassed result. Test expectation: 'PassLeadingZeroNibble'." Looking at the Z values for all the test cases in tgId: 4, this is the only Z value with a leading byte of 0's. I might guess that this has something to do with your IUT passing back a "failed" where "passed" is expected.

-Ben

[Kritner]

Please see these two comments for additional information around padding as it relates to SSC:

https://github.com/usnistgov/ACVP/issues/1196#issuecomment-865001574 https://github.com/usnistgov/ACVP/issues/1196#issuecomment-866109451

The comments themselves are specific to ECC SSC, but the same logic applies to FFC.

Most relevant bit from the linked comments:

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.

FFC's integer to byte array conversion is covered in appendix C.1 from SP800-56Ar3:

[abkarcher]

Thank you both very much for the information and links. I definitely have a good place to start looking. Awesome!

Thanks again, Andrew

[abkarcher]

Hello,

Yep, it seems like it was a padding issue; in earlier versions of OpenSSL 3.0 it looks you had to enable padding manually (which I was neglecting to do) and a recent update seemingly made that padding enabled by default. Not getting any more failures. Thanks!

Andrew