Mark use of `PKCS1v15` for encryption and decryption a vulnerability

[tomato42]

Is your feature request related to a problem? Please describe.
While pyca/cryptography is generally a high quality wrapper around OpenSSL, because of peculiarities of Python it is impossible to handle PKCS#1 v1.5 decryption failures in side channel free manner. As such, all usages of it will leak information useful in mounting the Bleichenbacher/Marvin attack: pyca/cryptography#9785

Describe the solution you'd like
Any use of the cryptography.hazmat.primitives.asymmetric.padding.PKCS1v15 for decryption (or encryption) should be marked as vulnerabilities.

Describe alternatives you've considered
it's impossible to handle exceptions in Python in side-channel free manner
the PKCS#1 v1.5 is known to be insecure for over 25 years at this point, it's high time to stop use of it

the alternative is to use RSA-OAEP encryption

Additional context
https://people.redhat.com/~hkario/marvin/

Love this idea? Give it a 👍. We prioritize fulfilling features with the most 👍.

[tomato42]

Same thing applies to python-rsa package: sybrenstuvel/python-rsa#230 but then, use of any private keys with it is insecure: https://github.com/sybrenstuvel/python-rsa#security not just PKCS#1 v1.5 decryption

[tomato42]

Same thing applies to the M2Crypto library: https://gitlab.com/m2crypto/m2crypto/-/issues/342

[tomato42]

The M2Crypto issue has been assigned CVE-2023-50781, the pyca/cryptography issue has been assigned CVE-2023-50782

[odony]

@tomato42 you're saying that using padding.PKCS1v15 for encryption should also be marked as a vulnerability. May I ask you to elaborate on that? Did you mean it in the sense that any encryption/signature operation has a decryption/signature verification counterpart somewhere, so it's best to consider them unsafe, even if the counterpart is implemented elsewhere with a different stack.

I'm thinking of the many APIs exposed by tax authorities everywhere in the world, which often require RSA signatures for documents being submitted - and are verified on their side. The emitting side could implement signatures in Python without any knowledge of how they will be decrypted/verified. Would that be considered unsafe?

Thanks!

[tomato42]

@tomato42 you're saying that using padding.PKCS1v15 for encryption should also be marked as a vulnerability. May I ask you to elaborate on that? Did you mean it in the sense that any encryption/signature operation has a decryption/signature verification counterpart somewhere, so it's best to consider them unsafe, even if the counterpart is implemented elsewhere with a different stack.

Because it's very unlikely that the decryption is implemented correctly.
also, the point of this recommendation is to deprecate use of it, so that no new PKCS#1v1.5 ciphertexts are created, so that there's less need for use of it. And any half-decent implementation can handle both PKCS#1v1.5 ciphertexts and RSA-OEAP ciphertexts.

I'm thinking of the many APIs exposed by tax authorities everywhere in the world, which often require RSA signatures for documents being submitted - and are verified on their side. The emitting side could implement signatures in Python without any knowledge of how they will be decrypted/verified. Would that be considered unsafe?

I'm talking about encryption, not signatures. Signatures with PKCS1v1.5 padding are fine.

[odony]

@tomato42 Thanks for the clarifications. I'm asking because Bleichenbacher's paper describes how to apply the algorithm to forge an RSA signature as well. As I understand it, that comes from the fact that generating a RSASSA-PKCS1-v1_5 signature¹ uses the private key in a manner that is similar to the decryption of a ciphertext. This is also described in section 3.4 of the ROBOT paper. That signature forgery attack is considered harder than for decryption because it requires the blinding first step described by Bleichenbauer, but it still seems possible with a working oracle.

In this context, one might consider that RSASSA-PKCS1-v1_5 signature operations should be marked as vulnerabilities for roughly the same reasons as for decryption. And therefore the use of cryptography.hazmat.primitives.asymmetric.padding.PKCS1v15 should be discouraged for signatures too. What am I missing here?

Thanks again :-)

EDIT: Answering myself to avoid more noise. I think I see what I missed initially. The signature forgery attack works with the exact same oracle as the attack on the decryption. It needs the RSA exponentiation with the private exponent to be applied by the server, which is what happens when the server is decrypting a message.
In this situation, by sending a crafted "message signature block" instead of a ciphertext, the server will try to decrypt it, which is actually the same exponentiation operation as signing it with the private key. The Bleichenbauer algorithm then allows the attacker to determine the corresponding "plaintext" for that "signature block", which is indeed the proper signature for that message.
So the main point is: this attack is only possible when the server accepts ciphertext messages to decrypt them. In a signature-only scheme, there is no possible oracle over a private key operation, because the signature verification only uses the public key. The signature forgery attack is only possible when an encryption scheme is used with the same private key.

Footnotes

1. https://www.rfc-editor.org/rfc/rfc8017#section-8.2 ↩

[tomato42]

yes, but moreover in the Bleichenbacher-like attack you need an oracle that tells you if the tested ciphertext decrypts to a plaintext that starts with specific bytes, in signing all inputs to the exponentiation start with specific bytes

also, while there are side-channel attacks on the signing operation, they are independent of used padding: PKCS#1v1.5 will be just as vulnerable as RSA-PSS

so, attacks on signatures and on encryption are completely different