CRYPTO_KEY_EXCHANGE(3MONOCYPHER)
β¨ CRYPTO_KEY_EXCHANGE β¨
okay so bestie, we're in monocypher, section 3, and it's LOCAL β and today's topic is Elliptic Curve Diffie-Hellman key exchange. like, the actual "two people who've never met agree on a secret" magic trick. it's giving β¨main character energyβ¨ fr fr π¦
two functions in the squad:
crypto_key_exchangecrypto_key_exchange_public_key
let's go π
πΈ SYNOPSIS πΈ
#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]);
π DESCRIPTION π
crypto_key_exchange() computes a shared key with your secret key and their public key. that's it, that's the whole vibe. two of you, one shared secret, nobody eavesdropping. periodt.
crypto_key_exchange_public_key() deterministically computes the public key from a random secret key. same secret key in β same public key out, every single time. no randomness, no surprises, just math being math π₯
π the arguments π
shared_keyβ the shared secret, known only to those who know a relevant secret key (yours or theirs). it's cryptographically random, and it's suitable for use with thecrypto_lock(3monocypher)family of functions. so like, this is your group-chat DM key, bestie π€«your_secret_keyβ a 32-byte random number, known only to you. seeintro(3monocypher)for advice about generating random bytes (use the operating system's random number generator β yes, <em>the OS one</em>, not your cousin's homemade RNG, pls π).their_public_keyβ the public key of the other party. the person you're exchanging with. your pen pal. your situationship. whoever πyour_public_keyβ your public key, generated fromyour_secret_keywithcrypto_key_exchange_public_key(). your little badge you hand out to everyone.
shared_key and your_secret_key may overlap if the secret is no longer required. cute, lowkey efficient, slay.
some poorly designed protocols require you to test for "contributory" behaviour, which ensures that no untrusted party forces the shared secret to a known constant. the move here is to not do that β 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. fix the protocol, not the symptom, bestie π«Ά
π¨ DO NOT use the same secret key for both key exchanges and signatures. the public keys are <em>different</em>, and revealing both may leak information. like, that's a whole mess. 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 withcrypto_from_eddsa_private(3monocypher)andcrypto_from_eddsa_public(3monocypher). problem solved, iconic π
β RETURN VALUES β
crypto_key_exchange() and crypto_key_exchange_public_key() return nothing. they just do the thing and dip. no return value, no drama, no notes π
π EXAMPLES π
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. (ngl, read that one, it matters π)
π¦ 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. yes, <em>the same one</em>. that's the whole point and it's honestly so iconic πΈ)
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);
π SEE ALSO π
π STANDARDS π
these functions implement X25519, described in RFC 7748. and crypto_key_exchange() uses HChacha20 as well. certified, standardized, no cap β¨
π HISTORY π
- 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.
a glow-up timeline fr fr π
π¨ SECURITY CONSIDERATIONS π¨
if either of the long term secret keys leaks, it may compromise all past messages. like, all of them. retroactively. the receipts π
this can be avoided by using protocols that provide forward secrecy, such as the X3DH key agreement protocol. use those. protect your past self. she deserves it π«Ά
π₯ IMPLEMENTATION DETAILS π₯
crypto_key_exchange_public_key() is an alias to crypto_x25519_public_key(3monocypher). that's the tea β
and that's the page, bestie!! this one shipped with Debian, dated March 31, 2020 β go forth and exchange some keys responsibly, mwah πβ¨π
π¦ where this page comes from
- fedora 43: monocypher-devel 3.1.2-12.fc43 Β· LicenseRef-Callaway-BSD OR CC0-1.0
- fedora 43: monocypher-devel 3.1.2-12.fc43 Β· LicenseRef-Callaway-BSD OR CC0-1.0
- fedora 44: monocypher-devel 3.1.2-13.fc44 Β· LicenseRef-Callaway-BSD OR CC0-1.0
- fedora 44: monocypher-devel 3.1.2-13.fc44 Β· LicenseRef-Callaway-BSD OR CC0-1.0
- π the page's license: BSD-2-Clause OR CC0-1.0
- Copyright (c) 2017-2019 Loup Vaillant
- Copyright (c) 2017-2018 Michael Savage
- Copyright (c) 2017, 2019-2020 Fabio Scotoni
- Copyright (c) 2020 Richard Walmsley
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms