A unit test, SignatureTest::test_sign_different_key, is failing occasionally. The reason for this is that the test expects the verify function to raise a VerificationError, but the test instead raises an OverflowError sometimes. This is because the otherpub modulus (i.e., the "different key" in the test) can be smaller than the signature. To address the issue, the test should be updated to expected either a VerificationError or an OverflowError.
The behavior was introduced with PR #206, where verifying was changed to instead use encrypt_int instead of decrypt_int. These methods are almost the same, but encrypt_int checks that the size of the message passed in is less than the size of the modulus. According to RFC 8017: PKCS#1 v2.2, all cryptographic primitives should be performing this check, so the behavior now is actually more correct and decrypt_int/decrypt_int_fast should be updated to check its argument's length as well. I will open this update as a separate issue.
I don't believe the failure to perform this check led to any vulnerabilities but I encourage everyone to review it.
A unit test,
SignatureTest::test_sign_different_key
, is failing occasionally. The reason for this is that the test expects the verify function to raise aVerificationError
, but the test instead raises anOverflowError
sometimes. This is because theotherpub
modulus (i.e., the "different key" in the test) can be smaller than the signature. To address the issue, the test should be updated to expected either aVerificationError
or anOverflowError
.The behavior was introduced with PR #206, where verifying was changed to instead use
encrypt_int
instead ofdecrypt_int
. These methods are almost the same, butencrypt_int
checks that the size of the message passed in is less than the size of the modulus. According to RFC 8017: PKCS#1 v2.2, all cryptographic primitives should be performing this check, so the behavior now is actually more correct anddecrypt_int
/decrypt_int_fast
should be updated to check its argument's length as well. I will open this update as a separate issue.I don't believe the failure to perform this check led to any vulnerabilities but I encourage everyone to review it.