(Feature) Curve25519 API that's harder to misuse.

[Yawning]

As discussed in #236, having something like this along with the NaCl box primitives will allow significantly easier use of the library, for the "I just want to encrypt/decrypt stuff without shooting myself in the foot with a shotgun" userbase.

This is probably related to #228.

Maybe something like: https://github.com/Yawning/rust-crypto/tree/curve25519_usability

use crypto::curve25519;
use std::rand::{OsRng, Rng};

let mut rng = try!(OsRng::new());
let my_private = curve25519::PrivateKey::new(&mut rng);
let my_public = my_private.as_bytes();

// Send public key to Bob...

let bobs_raw_public = /* a u8 slice with 32 bytes, read it off the network or something. */;
let bobs_public = curve25519::PublicKey::from_bytes(&bobs_raw_public);

let shared_secret = my_private.key_exchange(bobs_public); // <- [u8; 32] that's shared.

// Pass shared_secret through a KDF of your choice (really, use HKDF).

No pull request because the API more than likely could be improved, and it's a quick and dirty thing that tries to get the general idea across.

[Philipp91]

rust-crypto depends on rand anyway, why make the caller instantiate and pass in the rng? You could just have ::new_random() or sth like that. Some users might not know which of the RNGs to use.

let my_public = my_private.as_bytes(); That's confusing. When I call .as_bytes() on something, I expect to receive its raw contents, not something else. So the getter should have a different name, say, .get_public_key().

[u8; 32] is it always 32 bytes? Even when this API gets generalized a bit more?

[aep]

since this is rather dead, did you go for a different crate @Yawning ? If not it might be useful to use your code in a separate high level crate

[Yawning]

I haven't touched Rust in a personal capacity since around the time I last commented on this issue, sorry.