multiprime support #207
Merged
multiprime support #207
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added fast CRT-based decryption to core added multiprime key support correction (see issue sybrenstuvel#205, PR sybrenstuvel#206) added multiprime tests
|
To clarify, this PR only adds API support. If this PR is approved then I will be happy to work on extending the CLI to support multiprime encryption. |
|
This would be very useful, are there any updates on getting this merged in? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds multiprime support to help this library meet PKCS#1 v2.1. It's a big one! I didn't want to break existing user API to keep it backwards compatible. While this means it could be merged into the current library version, it also means the code gets more complicated at times (see
__repr__and__getstate__for examples).I also realized that some users may be depending on return type guarantees. For example, if a user is using
gen_keysdirectly (which I think is supposed to be an internal method, but it doesn't have a leading_) then their code would break because I made it behave differently for multiprime vs conventional key generation. To prevent this, I changed the return type totyping.Tuple, which will stop it from breaking but makes the typing less useful. I could've made ittyping.Union[typing.Tuple[int, int, int, int],typing.Tuple[int, int, int, int, typing.List[int]]but I don't think anyone would've appreciated that! I also have the changes from #205 and #206 since I found them in this branch first.