Create new types for keys and clear values on drop

[DebugSteven]

PR for issue #9

Created Ephemeral & SharedSecret types to use for keys.
diffie_hellman, generate_public, & generate_secret are now methods on Ephemeral.
Both types use clear in their respective drop implementations & Ephemeral has an implementation for Mul.

[hdevalence]

Could the build failure be related to rust-random/rand#645 ?

[hdevalence]

Moving the protocol flow into types looks great!

One thing I notice is that the ephemeral secret key (a Scalar) is encapsulated in Ephemeral struct, but the public key (a MontgomeryPoint) isn't. It seems like the types would match the protocol better if Ephemeral was renamed to EphemeralSecret, and the MontgomeryPoint was encapsulated in an EphemeralPublic.

Then the EphemeralSecret can have a new(csprng: &mut T) (instead of generate_secret, since the secret is part of the type already), the generate_public can become a From impl (since it's really a conversion, not generating something new), and the SharedSecret type can have an as_bytes to get the secret bytes at the end (right now there's no way to access the bytes of a SharedSecret). Then all the other methods could be removed -- for instance, it's not necessary to inspect the bytes of an EphemeralSecret, or to save it etc.

[hdevalence]

Is there a reason to expose this trait impl if the diffie_hellman function exists? My guess is that it's probably not necessary.

[hdevalence]

Is it really necessary to derive Default (instead of just calling self.0.clear() in the Drop impl)?

It seems like it would be better not to implement Default, so that the only way to create a SharedSecret is as the output of a DH function.

[hdevalence]

nit: I think these lifetime specifiers might be redundant

[hdevalence]

Now that there's an EphemeralPublic type (which already holds a MontgomeryPoint), there's no need to copy it into a new point and call the x25519 function ... in fact the entire x25519 function could be removed and combined into the diffie_hellman function.

Also, if diffie_hellman takes self rather than &self, then an EphemeralSecret can't be used more than once.

[hdevalence]

Hey, sorry for not having bandwidth for this until now. I think that the ephemeral DH API looks good. You asked (out-of-band) about whether the function should be provided as in the RFC or whether the same functionality should be provided by an API which is different than the way that the RFC is written.

One point is that the ephemeral DH API, as you've implemented it, forces the user to actually do ephemeral DH, only using the secret key once (since it's consumed by the DH function). This is stricter than what the x25519 function in the RFC allows. So maybe the best thing is to provide two "levels" of functionality: the ephemeral DH API, which is oriented around using Rust types to express protocol invariants (like no reuse of secret keys), as well as a bare, byte-oriented x25519 function that operates on raw bytes (and matches the RFC's spec more closely):

pub fn x25519(k: [u8; 32], u: [u8; 32]) -> [u8; 32] {
    (clamp_scalar(k) * MontgomeryPoint(u)).to_bytes()
}

Then this separation allows a few simplifications:

• Since EphemeralSecrets can only be created by their constructor, the bit-clamping invariant can be enforced by calling clamp_scalar in new, and the diffie_hellman implementation can be simplified to

pub fn diffie_hellman(self, their_public: &EphemeralPublic) -> SharedSecret {
    SharedSecret(self.0 * their_public.0)
}

• The repr(C)s on the ephemeral types can be eliminated (since if someone wants FFI, they can use the "bare" byte-oriented function);

[hdevalence]

note: with those changes the RFC tests need to be using the bare x25519 function, not the ephemeral API

[hdevalence]

LGTM