Add support for RSA signature recovery

[misterzed88]

First round of suggested changes for adding RSA signature recovery, as discussed in issue #5495.

[alex]

I think this should have a slightly less generic name. My opening suggestion would be `recover_digest_from_signature`.

…

On Fri, Nov 27, 2020 at 11:06 PM Paul Kehrer ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/cryptography/hazmat/backends/openssl/rsa.py <#5573 (comment)>: > @@ -463,3 +498,9 @@ def verify(self, signature, data, padding, algorithm): return _rsa_sig_verify( self._backend, padding, algorithm, self, signature, data ) + + def recover(self, signature, padding, algorithm): + _check_not_prehashed(algorithm) We should add a quick test to trigger this ------------------------------ In src/cryptography/hazmat/backends/openssl/rsa.py <#5573 (comment)>: > @@ -186,7 +186,14 @@ def _rsa_sig_setup(backend, padding, algorithm, key, data, init_func): _Reasons.UNSUPPORTED_HASH, ) res = backend._lib.EVP_PKEY_CTX_set_rsa_padding(pkey_ctx, padding_enum) - backend.openssl_assert(res > 0) + if res <= 0: + backend._consume_errors() + raise UnsupportedAlgorithm( + "{} is not supported for the RSA sigature operation.".format( Typo, signature. So this path is only reachable if you use EVP_PKEY_verify_recover_init and a non-PKCS1v15 padding? ------------------------------ In docs/hazmat/primitives/asymmetric/rsa.rst <#5573 (comment)>: > @@ -709,6 +709,37 @@ Key interfaces :raises cryptography.exceptions.InvalidSignature: If the signature does not validate. + .. method:: recover(signature, padding, algorithm) + + .. versionadded:: 3.3 + + Recovers the digest of the original message string from the signature. + Normally you should use the + :meth:`~cryptography.hazmat.primitives.asymmetric.rsa.RSAPublicKey.verify` + function to validate the signature. But there are some cases where you + may want to recover the digest of the original message. I believe you mentioned some specific protocols that expect to be able to recover the digest in the original issue -- could we elaborate a tiny bit here and add an example or two of where it's necessary? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5573 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBHTDFJTJKAHCFVWMZ3SSBZNPANCNFSM4TZ6AZTQ> .

-- All that is necessary for evil to succeed is for good people to do nothing.

[misterzed88]

Thanks for reviewing and good comments!

The current proposal does not implement the full signature data recovery feature (including DigestInfo), as mentioned in #5495. This was a small misunderstanding on my part - I now realize that you OKed that but only for the separate recovery case.

I will update the proposal with that feature, and the other things you mentioned.

[misterzed88]

I think this should have a slightly less generic name. My opening suggestion would be recover_digest_from_signature.

Yes, recover may sound a bit too ambiguous. What about recover_signature? Or, alternatively, recover_data_from_signature?

Technically, the function recovers any signature data (which may or may not be a digest), especially after I have made the planned changes where all types of data can be recovered, even without a DigestInfo block (as described in #5495).

[reaperhulk]

recover_data_from_signature seems fine.

[misterzed88]

Updated the suggested recovery functionality with an option to return all of the recovered signature data, by allowing None as hash algorithm parameter.

[misterzed88]

Thanks again for reviewing and good comments regarding how to improve the documentation. I planned on doing the suggested changes this week but just noticed that you already marked them as resolved. Should I still do the changes or have you moved on without them?

[alex]

Paul made the changes on your branch and I merged them (we're intendeding to do a release shortly and wanted to make sure this was included). Thanks!

…

On Mon, Dec 7, 2020 at 11:58 PM Zoltan Kelemen ***@***.***> wrote: Thanks again for reviewing and good comments regarding how to improve the documentation. I planned on doing the suggested changes this week but just noticed that you already marked them as resolved. Should I still do the changes are have you moved on without them? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#5573 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBHFLI3E3N6MEDCO2JDSTWXALANCNFSM4TZ6AZTQ> .

-- All that is necessary for evil to succeed is for good people to do nothing.

[misterzed88]

Ok, I see, thanks.

Are you sure Paul fixed the last-minute documentation changes that you proposed? (I couldn't see them included in commit 6693d55, but maybe I missed something).

[misterzed88]

The last document changes were added separately in #5614.

[reaperhulk]

@misterzed88 yeah, we did the changes...but didn't merge the right commit because I didn't actually commit, I just pushed a rebase. These were all docs so less critical of course, but generally we do prefer to merge them as one when the diff isn't too large. Sorry about the confusion.

[misterzed88]

Good to be reminded once in a while that we are all humans, to keep our humility. :)

Thanks for accepting the PR and for fixing the last issues in the docs.