Replace PKCS#1 v1.5 padding in RSA PCT#23832
Conversation
github-actions
bot
added
the
severity: fips change
|
Could you please add a comment block in the code about how you selected this as the PCT.. i.e. something similar to your comment above,, |
t8m
added
branch: master
|
@paulidale after looking at the requirements again, I'm reconsidering a sign/verify PCT. AS10.35 (and its VEs/TEs) of the FIPS 140-3 standard requires a PCT for every generated key pair. There are 3 options:
OpenSSL implements all three use cases: RSA-OAEP for key transport, RSA signatures with PKCS#1 v1.5 or PSS padding, and KAS-IFC-SSC (KAS1/KAS2) using RSASVE. According to FIPS 140-3 IG 10.3.A, if at the time when the PCT is performed the keys' intended usage is not known, then any of the three PCTs described in AS10.35 shall be performed on this key pair. Because of this allowance from the IG, and because KAS-IFC-SSC is now implemented, OpenSSL could switch to the PCT from SP 800-56Br2, i.e. RSA_public_encrypt and RSA_private_decrypt with RSA_NO_PADDING. That would keep the changes to the test itself to a minimum, and probably be a bit faster even than the sign/verify with PKCS#1 v1.5 padding. However, the main reason I'm not sure about this approach is that right now the test variable is named "OSSL_SELF_TEST_DESC_PCT_RSA_PKCS1", so the name kind of implies that PKCS#1 v1.5 padding will be used. |
|
I am not against creating another OSSL_SELF_TEST_DESC_PCT_RSA name.. |
jvdsn
changed the title
|
@paulidale let me know if you prefer this approach. |
|
This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago |
|
This PR is in a state where it requires action by @openssl/otc but the last update was 61 days ago |
|
This PR is in a state where it requires action by @openssl/otc but the last update was 92 days ago |
|
This PR is in a state where it requires action by @openssl/otc but the last update was 123 days ago |
|
This PR is in a state where it requires action by @openssl/otc but the last update was 154 days ago |
|
Maybe change whatever notation style check is complaining about. |
|
The style issue needs to be fixed. We've had problems with characters in source > 127. |
After December 31, 2023, SP 800-131Ar2 [0] no longer allows PKCS#1 v1.5 padding for RSA "key-transport" (aka encryption and decryption). There's a few good options to replace this usage in the RSA PCT, but signature generation and verification using PKCS#1 v1.5 padding (which remains approved) is the simplest. [0]: https://doi.org/10.6028/NIST.SP.800-131Ar2
After December 31, 2023, SP 800-131Ar2 [0] no longer allows PKCS#1 v1.5 padding for RSA "key-transport" (aka encryption and decryption). There's a few good options to replace this usage in the RSA PCT, but the simplest is verifying m = (m^e)^d mod n, (where 1 < m < (n − 1)). This is specified in SP 800-56Br2 (Section 6.4.1.1) [1] and allowed by FIPS 140-3 IG 10.3.A. In OpenSSL, this corresponds to RSA_NO_PADDING. [0]: https://doi.org/10.6028/NIST.SP.800-131Ar2 [1]: https://doi.org/10.6028/NIST.SP.800-56Br2
|
I believe it was the minus sign. |
|
Thanks, I was about to fix this and you beat me to it. |
paulidale
added
approval: done
paulidale
added
approval: ready to merge
|
Merged, thanks for sticking with this one. |
After December 31, 2023, SP 800-131Ar2 [0] no longer allows PKCS#1 v1.5 padding for RSA "key-transport" (aka encryption and decryption). There's a few good options to replace this usage in the RSA PCT, but signature generation and verification using PKCS#1 v1.5 padding (which remains approved) is the simplest. [0]: https://doi.org/10.6028/NIST.SP.800-131Ar2 Reviewed-by: Tomas Mraz <[email protected]> Reviewed-by: Shane Lontis <[email protected]> Reviewed-by: Paul Dale <[email protected]> (Merged from #23832)
After December 31, 2023, SP 800-131Ar2 [0] no longer allows PKCS#1 v1.5 padding for RSA "key-transport" (aka encryption and decryption). There's a few good options to replace this usage in the RSA PCT, but the simplest is verifying m = (m^e)^d mod n, (where 1 < m < (n − 1)). This is specified in SP 800-56Br2 (Section 6.4.1.1) [1] and allowed by FIPS 140-3 IG 10.3.A. In OpenSSL, this corresponds to RSA_NO_PADDING. [0]: https://doi.org/10.6028/NIST.SP.800-131Ar2 [1]: https://doi.org/10.6028/NIST.SP.800-56Br2 Reviewed-by: Tomas Mraz <[email protected]> Reviewed-by: Shane Lontis <[email protected]> Reviewed-by: Paul Dale <[email protected]> (Merged from #23832)
6 participants
After December 31, 2023, SP 800-131Ar2 0 no longer allows PKCS#1 v1.5 padding for RSA "key-transport" (aka encryption and decryption). There's a few good options to replace this usage in the RSA PCT, but the simplest is verifying m = (m^e)^d mod n, (where 1 < m < (n − 1)). This is specified in SP 800-56Br2 (Section 6.4.1.1) 1 and allowed by FIPS 140-3 IG 10.3.A. In OpenSSL, this corresponds to RSA_NO_PADDING.
Issue: openssl/project#241