Changes to PK ECDH API

[Synss]

The PR fulfills these requirements

• [ ] This change is a single feature in a single commit.
• [x] The commit message follows our commit guidelines.
• [x] The code formatting follows our coding guidelines.
• [x] Tests have been added for the changes.
• [x] Docs have been added / updated (docstrings and README).
• [x] A one-liner has been added to the ChangeLog (for new features).

More details in CONTRIBUTING.

I am submitting a …

• [ ] Bug fix
• [ ] New feature
• [ ] Tests update (new test vector, etc.)
• [ ] Docs update
• [x] Other (please complete)

Description

Other information

[Synss]

@stepheny : I have been thinking about the EC API and this is what I have done. Since I know that you are using that part of the library, would you like to comment before I merge these changes? Finally, I have refactored your tests in 09c965004d07c8fcc72e18ab4e11b41e571b5cf0 and you may want to see whether I understood your code correctly.

[stepheny]

Thank you for informing the API change. Since you decided to use all public properties, I think you could just change them and remove the private ones. I think it's good to do the transition as early as possiple. Having both versions of the same functions at the same time might be confusing. About the tests, I think they are okay. Originally, I've just written some simple accesses to different stages of secret exchange in order to cover the getters and setters. I doubt these simple codes match the ideas of authenticate or attack... Never mind, no matter what it's named it should do the work.

[Synss]

@stepheny

• Regarding the properties: I have public getters but private setters. I see from your tests that the setters may be useful. However, my goal would be to keep most classes immutable. A ECDHBase.from_private_key() class method may be a solution, though. I will deprecate or remove the private properties when I have something better.
• For the tests, do you have better names?

[stepheny]

• Asymmetry getters and setters... are pretty new to me, I've never seen before. If you think it is right then no problem. It's a good idea to keep things immutable, but key agreement is kind of a stateful procedure. A key agreement context might more or less need some state variables. ECDHNaive is so simple that it can be immutable but may not apply to other schemes. If someone really want to make it immutable, then it should be a tuple of curve, private_key(generate or load), and public_key(generate on instantiation). Then exchange method should be a pure function accepts only the tuple(self) and peer's public_key and returns the sharedsecret. Current generate* methods made no sense to immutables.
• I've no idea.

[Synss]

Thank you for your feedback.