Vector Not Received on Official Server

[hbarton-atsec]

Hi,

I'm having an issue on the official server where testID 13098 / vsID 136740 doesn't seem to be received properly resulting in an Unverified verdict. Any help getting this vector to process is much appreciated.

[livebe01]

Hi @hbarton-atsec, just wanted to let you know that we're looking into this. It looks like you submitted the vector set results, but that there was an error scoring them. I was digging to find the source of the error, but couldn't quite run it down today. Should be able to get you an answer early next week.

[hbarton-atsec]

No worries! I appreciate you guys looking into this and have a good weekend.

[livebe01]

I think I've tracked the error down to "tgId":5. From looking at our codebase, the error appears to indicate that the z value(s) provided by the IUT for one or more of the test cases are not the correct length.

[hbarton-atsec]

The modulo is defined to be 512 bytes. iutN and serverC are both 512 bytes. Similarly, the resulting Z is 512 bytes. I don't see how z value is wrong for any of the tcId's in tgId 5 as the the Z is equal in size as the modulus.

[livebe01]

Agreed, I'm pretty sure this is an issue on our end.

[hbarton-atsec]

Ok just let me know if you need something from my side to get this resolved. Thanks again for all your help.

[livebe01]

Okay, I found where I was off. It's tgId 1, not 5 and the iutC value, not the Z. The server is throwing an error for tcId 3 for the iutC value, as it is 2040 bits where a 2048 bit value is expected. It could be that the IUT is truncating a leading 0x00 byte?

[hbarton-atsec]

Hi,

We've decided to drop this specific algorithm from the module we are testing. Thanks for digging into the issue and being so helpful!

[smuellerDD]

Some long time ago, the server had the issue that the bignum library required leading zeros. According to Chris, this was fixed long time ago with the replacement of that library on the server. Is this not true any more, i.e. do we now need to take care about leading zeros again?

[livebe01]

@smuellerDD that's not what is happening here. For this test, the IUT is supplying a C and a Z value as its answers. SP 800-56Br2 section 8.2.2 describes deriving Z for KAS1-basic as (Z, C) = RSASVE.GENERATE(PubKeyV). In section 7.2.1.2 we see that "Z, a byte string of nLen bytes" and "C = I2BS(c, nLen)." By definition C and Z are both byte strings of length nLen. The server is throwing an error because the provided C is 255 bytes whereas the provided Z is 256 bytes. According to the SP len(Z) should equal len(C).

[smuellerDD]

Yes, it is. According to Chris this issue was solved at the ACVP server by using a different binging library. Are you saying that zero-padding is again necessary?

Ciao Stephan

— Cui bono?

Am 03.05.2022 um 21:47 schrieb livebe01 @.***>:

 Okay, I found where I was off. It's tgId 1, not 5 and the iutC value, not the Z. The server is throwing an error for tcId 3 for the iutC value, as it is 2040 bits where a 2048 bit value is expected. It could be that the IUT is truncating a leading 0x00 byte?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[livebe01]

In order to conform with the SP, the IUT must produce a C s.t. len(C) equals len(Z) equals nLen. If zero padding is required to accomplish this, then I believe that we would expect that the zero padding would be performed by the IUT and not the test harness.