cryptography
cryptography copied to clipboard
pyca
Any update on mitigation CVE-2020-25659?
I read the instructions at https://cryptography.io/en/latest/security.html, but this is not a new report, I don't believe those instructions apply.
PR #5507, which states "we cannot completely mitigate this vulnerability and a future release will contain a new API which is designed to be resilient to these for contexts where it is required", was merged almost 9 months ago.
Has there been any progress with the mentioned new API?
Hello! We'd love to see and request a new API for this. Currently, us security folks are reporting the Timing Attack here https://snyk.io/vuln/SNYK-PYTHON-CRYPTOGRAPHY-1022152 and for genuine security reasons would like to see a fixed later version than 3.2 & 3.4.7. Thank you!
Have you considered to commission a fix and pay somebody to address the issue? It sounds like you need a fix for business and compliance reasons.
CVE-2020-25659 description:
python-cryptography 3.2 is vulnerable to Bleichenbacher timing attacks in the RSA decryption API, via timed processing of valid PKCS#1 v1.5 ciphertext.
PR #5507 statement:
"we cannot completely mitigate this vulnerability and a future release will contain a new API which is designed to be resilient to these for contexts where it is required"
@reaperhulk I was reading about this a bit today and have some questions and comments that I hope you might have time to answer or comment on.
- Is it possible to completely mitigate Bleichenbacher in PKCS#1 v1.5? That is, is it possible to define a new API to python-cryptography using PKCS#1 v1.5 that completely mitigates Bleichenbacher? From the little that I've read, the PKCS#1 v1.5 specification is fundamentally vulnerable to Bleichenbacher, so it would not be possible to implement a new API for PKCS#1 v1.5 that completely mitigates Bleichenbacher.
- Again, from what little I've read, RSAES-OAEP can completely mitigate Bleichenbacher. So could the new API that is mentioned in PR #5507 be based on OAEP? Would such an API mitigate CVE-2020-25659?
- There is at least one Python implementation of OAEP that has a friendly license (Public Domain/BSD2), PyCryptodome's (doc). Could this be leveraged to add a new API based on OAEP to python-cryptography? See also the PyCryptodome warning against using PKCS#1 v1.5.
- Sort of! You can do what TLS libs do, and this API does https://pkg.go.dev/crypto/rsa#DecryptPKCS1v15SessionKey the important bit is that you can't handle failures.
- OAEP does not suffer from Belichenbacher issues, but you can't just use it in place of PKCS1v1.5 when you have an existing protocol (ala TLS)
- We already support OAEP in cryptography.
On Tue, Nov 30, 2021 at 6:25 PM Tony Homer @.***> wrote:
CVE-2020-25659 https://github.com/advisories/GHSA-hggm-jpg3-v476 description:
python-cryptography 3.2 is vulnerable to Bleichenbacher timing attacks in the RSA decryption API, via timed processing of valid PKCS#1 v1.5 ciphertext.
PR #5507 https://github.com/pyca/cryptography/pull/5507 statement:
"we cannot completely mitigate this vulnerability and a future release will contain a new API which is designed to be resilient to these for contexts where it is required"
@reaperhulk https://github.com/reaperhulk I was reading about this a bit today and have some questions and comments that I hope you might have time to answer or comment on.
- Is it possible to completely mitigate Bleichenbacher in PKCS#1 v1.5 https://www.rfc-editor.org/rfc/rfc3447#section-7.2? That is, is it possible to define a new API to python-cryptography using PKCS#1 v1.5 that completely mitigates Bleichenbacher? From the little that I've read, the PKCS#1 v1.5 specification is fundamentally vulnerable to Bleichenbacher, so it would not be possible to implement a new API for PKCS#1 v1.5 that completely mitigates Bleichenbacher.
- Again, from what little I've read, RSAES-OAEP https://www.rfc-editor.org/rfc/rfc3447#section-7.1 can completely mitigate Bleichenbacher. So could the new API that is mentioned in PR #5507 https://github.com/pyca/cryptography/pull/5507 be based on OAEP? Would such an API mitigate CVE-2020-25659 https://github.com/advisories/GHSA-hggm-jpg3-v476?
- There is at least one Python implementation of OAEP that has a friendly license (Public Domain/BSD2), PyCryptodome's https://github.com/Legrandin/pycryptodome/blob/master/lib/Crypto/Cipher/PKCS1_OAEP.py (doc https://pycryptodome.readthedocs.io/en/latest/src/cipher/oaep.html). Could this be leveraged to add a new API based on OAEP to python-cryptography? See also the PyCryptodome warning against using PKCS#1 v1.5 https://pycryptodome.readthedocs.io/en/latest/src/cipher/pkcs1_v1_5.html#pkcs-1-v1-5-encryption-rsa.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pyca/cryptography/issues/6167#issuecomment-983119802, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAGBGBHCLQAG5PNM76X53UOVMPHANCNFSM5AFXRCUQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
-- All that is necessary for evil to succeed is for good people to do nothing.
I think I get it.
The current PKCS#1 v1.5 API in python-cryptography does not take a session key (similar to DecryptPKCS1v15), so a new PKCS#1 v1.5 API would be added to python-cryptography that does take a session key, and uses it as described in DecryptPKCS1v15SessionKey to avoid timing attacks. This mitigation approach is also described here.
The diff between DecryptPKCS1v15 and DecryptPKCS1v15SessionKey could serve as a reference for how to implement the new PKCS#1 v1.5 API in python-cryptography.
Is that right?
That's right.
On Tue, Nov 30, 2021 at 6:43 PM Tony Homer @.***> wrote:
I think I get it.
The current PKCS#1 v1.5 API in python-cryptography does not take a session key (similar to DecryptPKCS1v15), so a new PKCS#1 v1.5 API would be added to python-cryptography that does take a session key, and uses it as described in DecryptPKCS1v15SessionKey to avoid timing attacks. This mitigation approach is also described here.
The diff between DecryptPKCS1v15 and DecryptPKCS1v15SessionKey could serve as a reference for how to implement the new PKCS#1 v1.5 API in python-cryptography.
Is that right?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
-- All that is necessary for evil to succeed is for good people to do nothing.
The status of this ticket has not changed. As we have expressed: this issue has been mitigated as well as is possible under our current APIs, and if someone is interested in contributing a new API we'd be delighted to consider that.
@reaperhulk and I have conducted an exhaustive review of this issue to try to determine what action should be taken.
OpenSSL does not expose an API for straightforwardly implementing this while reusing its own constant-time logic. Specifically, OpenSSL's choices are 1) PKCS1v15 decryption with error checking (which is not constant time), 2) a TLS specific code path that is constant time, but contains many hardcoded assumptions, 3) performing "raw" RSA decryption and then allowing the caller to do padding validation.
(1) is the status quo, with us doing everything we can to mitigate and minimize the constant time elements.
(2) is not useful to us, since we have a general purpose API, and I don't understand anyone's use case here to actually be TLS. It's also unclear, without further investigation, if this API is truly usable outside of OpenSSL itself.
(3) is functionally possible, but puts the onus on us to write a fair bit of extremely sensitive code, with high requirements for validation to ensure they are both correct and constant time.
On review, we have decided that the balance here indicates that we should wontfix this. There is not a clear motivating use case in this thread and PKCS1v15 in online contexts (where this issue is relevant) are increasingly marginal as the ecosystem moves towards protocols with ephemeral key exchanges (RSA decryption is nearly entirely gone from the world of TLS at this point). In light of these, we don't believe the burdens of implementing this logic ourselves are justified by the value of adding such an API.
OpenSSL does not expose an API for straightforwardly implementing this while reusing its own constant-time logic. Specifically, OpenSSL's choices are...
Would it be worth discussing with upstream openssl whether it'd be reasonable/welcome to (4) add such an API upstream?
Folks are welcome to do so but we won’t be investing time ourselves given our findings above.
(2) is not useful to us, since we have a general purpose API, and I don't understand anyone's use case here to actually be TLS. It's also unclear, without further investigation, if this API is truly usable outside of OpenSSL itself.
also, that API has proper constant-time mitigations only when it's used with an online protocol like TLS that has server-controlled and public random data fed into the KDF together with the output of the decryption process. If the random value would be static for all KDF calls (e.g. in S/MIME) then it wouldn't be secure either.
The PR lingered because I didn't get info what's necessary to make it mergeable, I have that now and I'm working on an update to the https://github.com/openssl/openssl/pull/13817 right now.
For people not monitoring the openssl issue: it has been merged.
Ask your OS vendor to get it backported if RSA decryption in python is something you need.
note that updates are required to the cryptography test suite, https://github.com/pyca/cryptography/pull/7895 contains that