DH_GENERATE_KEY(3SSL)

πŸ’– DH_GENERATE_KEY(3SSL) πŸ’–

okay bestie, buckle up, this is the DH_GENERATE_KEY(3SSL) page from the OpenSSL manual set, and we're about to talk Diffie-Hellman key exchange. it's giving cryptography, it's giving deprecated, it's giving "please use the EVP stuff instead." let's get into it 🧚✨


🌸 NAME 🌸

DH_generate_key, DH_compute_key, DH_compute_key_padded β€” perform Diffie-Hellman key exchange. yes, all three of them, they're a little trio, a friend group 🫢


✨ SYNOPSIS ✨

#include <openssl/dh.h>

okay so important heads up before the function list: the following functions have been deprecated since OpenSSL 3.0, and you can hide them entirely by defining OPENSSL_API_COMPAT with a suitable version value β€” peep openssl_user_macros(7) for the deets πŸ’…

int DH_generate_key(DH *dh);

int DH_compute_key(unsigned char *key, const BIGNUM *pub_key, DH *dh);

int DH_compute_key_padded(unsigned char *key, const BIGNUM *pub_key, DH *dh);

πŸ’œ DESCRIPTION πŸ’œ

first things first, and I need you to hear me on this one: all of the functions described on this page are deprecated. not one, not two, ALL. 😭

applications should instead use EVP_PKEY_derive_init(3) and EVP_PKEY_derive(3). that's the move. that's the main character path. periodt.

DH_generate_key() does the first step of a Diffie-Hellman key exchange β€” it generates the private and public DH values. then by calling DH_compute_key() or DH_compute_key_padded(), those get combined with the other party's public value to compute the shared key. it's a whole collaboration, it's a duet πŸŽ€

DH_generate_key() expects dh to contain the shared parameters dh->p and dh->g. it generates a random private DH value unless dh->priv_key is already set, and then computes the corresponding public value dh->pub_key, which can then be published. go publish it, bestie, it's your moment ✨

DH_compute_key() computes the shared secret from the private DH value in dh and the other party's public value in pub_key, and stores it in key. key must point to DH_size(dh) bytes of memory. okay and the padding style here is RFC 5246 (8.1.2), which strips leading zero bytes. so β€” and I need you to clock this β€” it is not constant time, because those leading zero bytes get stripped. the return value should be considered public. like, public public. do not be out here treating it like a secret πŸ™ˆ

DH_compute_key_padded() is similar but stores a fixed number of bytes. its padding style is NIST SP 800-56A (C.1), which retains leading zero bytes. and bc of that retention, it is constant time. the return value here should also be considered public. same vibe, different padding, iconic behavior honestly πŸ‘‘


πŸ”₯ RETURN VALUES πŸ”₯

  • DH_generate_key() β€” returns 1 on success, 0 otherwise. simple. binary. no notes.
  • DH_compute_key() β€” returns the size of the shared secret on success, -1 on error.
  • DH_compute_key_padded() β€” returns DH_size(dh) on success, -1 on error.

and if you're sitting there like "okay but what was the error 😭" β€” you can get the error codes with ERR_get_error(3). there's your answer, you're welcome 🫢


πŸ¦‹ SEE ALSO πŸ¦‹

(the lore is all connected, iykyk)


🌈 HISTORY 🌈

  • DH_compute_key_padded() was added in OpenSSL 1.0.2. baby's first appearance πŸŽ€
  • All of these functions were deprecated in OpenSSL 3.0. rip to them fr fr πŸ’€

Copyright 2000-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


and that's the whole page, bestie!! go forth and use EVP_PKEY_derive like the responsible icon you are πŸ’…βœ¨

okay bye ily, this was version 4.0.3, dated 2026-09-29 β€” signed, sealed, DH_GENERATE_KEY(3SSL), and delivered with love πŸ«ΆπŸ’–πŸŒΈ

πŸ“¦ where this page comes from