Ecdhe #101
Ecdhe #101
Conversation
Conflicts: .gitignore OpenSSL/test/test_ssl.py
It would be great if there were a clean way to enumerate them rather than just listing them like this, but I don't know of one.
…rves Different OpenSSL builds support different curves. Determine the supported curves at startup and expose the list.
Using NIDs is awkward and requires updating pyOpenSSL every time a new curve is added. This approach avoids needing to update pyOpenSSL each time a new curve is added, and it results in more readable code and a more readable dict ELLIPTIC_CURVE_DESCRIPTIONS.
that we access them by name.
This also ninja-fixes the typo that was in the previous comment.
This sneakily fixes some test cases typos, too.
…t" does not install them in a way that makes them available later.
… edge case (but the weird edge case is still there inside OpenSSL), and add a bit of docs.
Happily, this eliminates just about all of the error cases.
|
Would it make sense to use the same/similar abstraction to preserve the interface being changed in #96? That PR seems to change the method signature because a curve has some extra bits of information required to generate keys. I think we'd also need to add trivial abstractions for RSA/DSA type keys, but I think it would lead to a more OO implementation of Thoughts? |
|
Looks like a reasonable interface. Here are a couple of things I don't like, though:
|
|
Thanks for the review!
This seems reasonable.
It already uses OpenSSL APIs. Lots of them. 😄 Can you be more specific? As far as I know, there isn't an API for retrieving a curve by name. The APIs for looking up a NID for a name and a curve for a NID introduce extra failure modes that I was happy to eliminate in the latest refactoring. If performance ends up being important here (I doubt it will) then maybe just some style of memoization of this work would be good enough? |
|
If this is going to be performance sensitive, it definitely seems like a On Tue, Apr 29, 2014 at 12:52 PM, Jean-Paul Calderone <
"I disapprove of what you say, but I will defend to the death your right to |
|
I think that the extra failure modes for converting name to NID don't matter in practice. If you feed a name of a curve that get_elliptic_curves returns into OBJ_sn2nid and OBJ_sn2nid fails, then your OpenSSL implementation is just broken. |
... and this has never happened to anyone. 😉 |
…ity does what we want.
Add basic support for using ECDHE.
5 participants
Update of #89, #82, #71, #57, #9
This changes the interface in a small but significant way - curves are now represented by an explicit object with a
nameattribute and some other private attributes. This approach eliminates nearly all of the error conditions that the previous PRs tried to deal with (and thus eliminates the question of what the exceptions for those error conditions should look like).It also tweaks some naming to bring it in line with the underlying OpenSSL APIs which is generally how pyOpenSSL naming has been done up to this point.