RSASP1 differences between ACVP and CAVS

[smuellerDD]

Barring detailed implementation knowledge, we derived the following results from studying the test vectors using the standard key type:

• CAVS: a valid key pair is generated using e=0x10001 from which n and d are sent to the IUT

• ACVP: seemingly random values for n and d are generated without using a known e and without using p and q factors to construct d.

Our IUT has an issue with the ACVP approach: The modular exponentiation logic requires a valid key (n, d) as otherwise the key components are not accepted. Changing this logic for testing is not possible as it would completely alter the IUT which would make the test results irrelevant for the real-life logic.

Further, our IUT implements an additional step which requires the knowledge of e. It is certainly possible to deactivate the additional step for testing if the ACVP implementation cannot be changed.

Thus, may we ask:

• the (n, d) key should be a valid key derived from proper p/q values

• if possible, the (n, d) key pair should have a fixed e

Note: the ACVP test vectors for RSASP1 do not work with https://nmichaels.org/rsa.py whereas CAVS does.

[celic]

When RSASP1 was originally written we didn't have a fast way to request a key. It was awkward to perform the full key generation process only to discard the key by generating a message too large to be signed.

Now we have pools for key values so the key request is no longer an issue, but the gen/vals here were never updated to account for that. This can be fixed rather easily.

[dsikkema-atsec]

Is there a plan to get this fixed, or is it fixed already? We have a vendor wanting to claim RSASP1.

[celic]

This has not been fixed yet. Let me see how much effort would be involved. If it can be squeezed in this week, I'll try to accommodate. There is no promise for when it would be available on demo or prod. We are scheduling a deployment out this week and could fit this in with it potentially.

[celic]

@smuellerDD As I'm looking now, the keys are valid keys. We just do not provide the public exponent in the prompt. I can update it so that we do provide the public exponent. Right now as well, we only support random public exponents. I could potentially update this to allow for fixed values. Thoughts?

[smuellerDD]

Please provide e. And yes, if you can add the option to request a fixed e, that would be all that is needed.

[celic]

Great. Hopefully we can roll this out very soon.

[smuellerDD]

May I ask for a hint by when you could have an update out? Thank you.

[dsikkema-atsec]

Is there a target date for the fix for this and/or 818?

[celic]

This will be likely after the current wave of refactors hit demo.

[Kritner]

This change should be out on demo, and in the next prod release.

[tobyp]

Thanks for implementing these changes! However, I am now unable to obtain any vectors. The spec does not seem to be updated with the new capability registration format yet. (Note the new Metanorma algorithm list has a "signatureComponent" test now, not a "signaturePrimitive". If that turns out to be independent of this issue, I would create a new issue for it later.)

Old Capabilities Format

[{"acvVersion": "1.0"}, {"algorithms": [{"algorithm": "RSA", "mode": "signaturePrimitive", "revision": "1.0", "keyFormat": "crt"}]}]
poduces the error:
[{"acvVersion": "1.0"}, {"error": "Validation error(s) on JSON payload.", "context": ["RSA-signaturePrimitive-1.0: Invalid public exponent mode."]}]

Guess: pubExpMode and fixedPubExp like RSA keyGen

[{"acvVersion": "1.0"}, {"algorithms": [{"algorithm": "RSA", "mode": "signaturePrimitive", "revision": "1.0", "keyFormat": "crt", "pubExpMode": "fixed", "fixedPubExp": "010001"}]}]
produces the same error.

Guess pubExpMode to random like RSA keyGen

[{"acvVersion": "1.0"}, {"algorithms": [{"algorithm": "RSA", "mode": "signaturePrimitive", "revision": "1.0", "keyFormat": "crt", "pubExpMode": "random"}]}]
produces the same error.

[celic]

Names have been fixed in the README. RSA spec has not been updated yet for this change. The JSON property names were not set to match other modes of RSA and that is a bug here. I'll fix that for the next update and the spec will match those names. For now, you can test with the properties "publicExponentMode" as "random" and "fixed" and "publicExponent" as the hex of the public exponent when the mode is "fixed".