Boring crypto that simply works

Key Exchange (Public Key Cryptography)

#include <monocypher.h>

crypto_key_exchange(uint8_t shared_key[32], const uint8_t your_secret_key[32], const uint8_t their_public_key[32]);

crypto_key_exchange_public_key(uint8_t your_public_key[32], const uint8_t your_secret_key[32]);

() computes a shared key with your secret key and their public key.

() deterministically computes the public key from a random secret key.

These functions are in favor of using a higher level protocol with crypto_x25519().

The arguments are:

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() family of functions.
A 32-byte random number known only to you. See intro() for advice about generating random bytes (use the operating system's random number generator).
The public key of the other party.
Your public key, generated from your_secret_key with ().

shared_key and your_secret_key may overlap if the secret is no longer required.

Some poorly designed protocols require a 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() and crypto_from_eddsa_public().

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() 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(), intro()

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. Both were deprecated in Monocypher 3.1.3 and are planned to be removed in Monocypher 4.0.0.

If either of the long-term secret keys leaks, it may compromise . This can be avoided by using protocols that provide forward secrecy, such as the X3DH key agreement protocol.

Many (private, public) key pairs produce the same shared secret. Therefore, not including the public keys in the key derivation can lead to subtle vulnerabilities. This can be avoided by hashing the shared secret concatenated with both public keys. For example,

BLAKE2b(shared_secret || your_pk || their_pk)
using crypto_blake2b().

() is an alias to crypto_x25519_public_key().

February 12, 2022 Debian