Crates.io | x448 |
lib.rs | x448 |
version | 0.6.0 |
source | src |
created_at | 2020-05-30 18:08:11.449049 |
updated_at | 2020-06-02 17:25:52.280178 |
description | A pure-Rust implementation of X448. |
homepage | https://github.com/crate-crypto/x448 |
repository | https://github.com/crate-crypto/x448 |
max_upload_size | |
id | 247765 |
size | 22,860 |
This is a pure Rust implementation of the Diffie hellman key exchange protocol, X448.
In the following example, Alice has an Ephemeral(One-Time use) Secret key and Bob has a Static(Multiple use) Key.
In this stage, both parties generate a secret and send the corresponding public key to the other party.
let alice_secret = Secret::new(&mut OsRng);
let alice_public_key = PublicKey::from(&alice_secret);
let bob_secret = Secret::from_bytes(bytes_of_key);
let bob_public_key = PublicKey::from(&bob_secret);
Both parties now have enough information to compute the shared key. They now independently compute the shared key.
let alices_shared_secret = alice_secret.to_diffie_hellman(&bob_public_key);
let bobs_shared_secret = bob_secret.as_diffie_hellman(&alice_public_key);
That's it. Kinda.
If neither Alice or Bob used a low order point, then they will both have the same shared_key. If one party, did indeed manage to circumvent the API and the honest party tries to use this low order point in a Diffie-hellman key exchange, the shared key will return None.
Notice that Alice used a method named to_diffie_hellman
while Bob used a method named as_diffie_hellman
. Using to_diffie_hellman
will consume the Secret key, denoting that the key can only be used once in a Diffie-Hellman Key exchange. Of course, you could copy it before it was consumed, but then it would have been more efficient to use as_diffie_hellman
.
The API exposes 3 structures; a public key , a shared secret key and a secret key.
In our API there is only one Secret Scalar Key. In X25519-Dalek there are two types of secret scalar keys;
Following the example above, this API achieves this example by using two methods on the same struct to_diffie_hellman
and as_diffie_hellman
. The rationale for choosing this API is that there will be less code duplication, as there is only one struct. Furthermore, this API also achieves the compile time guarantee that if the user wants to treat the Secret key as Ephemeral, then it will only be used once. One disadvantage of this API, is the lack of distinction between Secrets. For example, as a consumer of an API it would be advantageous to state that the type I want to accept is an EphemeralSecret
, this decreases the reading complexity as the type encodes the fact that it can only be used once in an diffie-hellman key exchange.