crypto_key_exchange,
crypto_key_exchange_public_key —
Elliptic Curve Diffie-Hellman key exchange
#include
<monocypher.h>
void
crypto_key_exchange(
uint8_t
shared_key[32],
const uint8_t
your_secret_key[32],
const uint8_t
their_public_key[32]);
void
crypto_key_exchange_public_key(
uint8_t
your_public_key[32],
const uint8_t
your_secret_key[32]);
crypto_key_exchange() computes a shared key with
your secret key and their public key.
crypto_key_exchange_public_key() deterministically
computes the public key from a random secret key.
The arguments are:
-
-
- shared_key
- The shared secret, known only to those who know a relevant
secret key (yours or theirs). It is cryptographically random, and suitable
for use with the
crypto_lock(3monocypher)
family of functions.
-
-
- your_secret_key
- A 32-byte random number, known only to you. See
intro(3monocypher) for
advice about generating random bytes (use the operating system's random
number generator).
-
-
- their_public_key
- The public key of the other party.
-
-
- your_public_key
- Your public key, generated from
your_secret_key with
crypto_key_exchange_public_key().
shared_key and
your_secret_key may overlap if the secret is
no longer required.
Some poorly designed protocols require to test for “contributory”
behaviour, which ensures that no untrusted party forces the shared secret to a
known constant. Protocols should instead be designed in such a way that no
such check is necessary, namely by authenticating the other party or
exchanging keys over a trusted channel.
Do not use the same secret key for both key exchanges and signatures. The public
keys are different, and revealing both may leak information. If there really
is no room to store or derive two different secret keys, consider generating a
key pair for signatures and then converting it with
crypto_from_eddsa_private(3monocypher)
and
crypto_from_eddsa_public(3monocypher).
crypto_key_exchange() and
crypto_key_exchange_public_key() return nothing.
The following examples assume the existence of
arc4random_buf(), which fills the given buffer
with cryptographically secure random bytes. If
arc4random_buf() does not exist on your system,
see
intro(3monocypher) for
advice about how to generate cryptographically secure random bytes.
Generate a public key from a randomly generated secret key:
uint8_t sk[32]; /* Random secret key */
uint8_t pk[32]; /* Public key */
arc4random_buf(sk, 32);
crypto_key_exchange_public_key(pk, sk);
/* Wipe secrets if they are no longer needed */
crypto_wipe(sk, 32);
Generate a shared, symmetric key with your secret key and their public key. (The
other party will generate the same shared key with your public key and their
secret key.)
const uint8_t their_pk [32]; /* Their public key */
uint8_t your_sk [32]; /* Your secret key */
uint8_t shared_key[32]; /* Shared session key */
crypto_key_exchange(shared_key, your_sk, their_pk);
/* Wipe secrets if they are no longer needed */
crypto_wipe(your_sk, 32);
crypto_lock(3monocypher),
intro(3monocypher)
These functions implement X25519, described in RFC 7748.
crypto_key_exchange() uses HChacha20 as well.
The
crypto_key_exchange() function first appeared
in Monocypher 0.2. The
crypto_key_exchange_public_key() macro alias
first appeared in Monocypher 1.1.0.
If either of the long term secret keys leaks, it may compromise
all past messages. This can be avoided by using
protocols that provide forward secrecy, such as the X3DH key agreement
protocol.
crypto_key_exchange_public_key() is an alias to
crypto_x25519_public_key(3monocypher).