From 6aecef815c3c989f6fa2a7b6edf2984e76306622 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Bodo=20M=C3=B6ller?= Date: Wed, 25 Jul 2001 17:20:34 +0000 Subject: [PATCH] Don't preserve existing keys in DH_generate_key. --- CHANGES | 31 +++++++++++++++++++++++++++++++ crypto/dh/dh_key.c | 16 ++++++++++------ doc/crypto/DH_generate_key.pod | 7 ++++--- 3 files changed, 45 insertions(+), 9 deletions(-) diff --git a/CHANGES b/CHANGES index 8cbb473650..feeb46e9b2 100644 --- a/CHANGES +++ b/CHANGES @@ -12,6 +12,37 @@ *) applies to 0.9.6a/0.9.6b/0.9.6c and 0.9.7 +) applies to 0.9.7 only + *) In crypto/dh/dh_key.c, change generate_key() (the default + implementation of DH_generate_key()) so that a new key is + generated each time DH_generate_key() is used on a DH object. + + Previously, DH_generate_key() did not change existing keys + -- but ssl/s3_srvr.c always expected it to do so (in effect, + SSL_OP_SINGLE_DH_USE was ignored in servers reusing the same SSL + object for multiple connections; however, each new SSL object + created from an SSL_CTX got its own key). + [Bodo Moeller] + + *) In OpenSSL 0.9.6a and 0.9.6b, crypto/dh/dh_key.c ignored + dh->length and always used + + BN_rand_range(priv_key, dh->p). + + BN_rand_range() is not necessary for Diffie-Hellman, and this + specific range makes Diffie-Hellman unnecessarily inefficient if + dh->length (recommended exponent length) is much smaller than the + length of dh->p. We could use BN_rand_range() if the order of + the subgroup was stored in the DH structure, but we only have + dh->length. + + So switch back to + + BN_rand(priv_key, l, ...) + + where 'l' is dh->length if this is defined, or BN_num_bits(dh->p)-1 + otherwise. + [Bodo Moeller] + *) In RSA_eay_public_encrypt diff --git a/crypto/dh/dh_key.c b/crypto/dh/dh_key.c index 91af882e43..718a9a481e 100644 --- a/crypto/dh/dh_key.c +++ b/crypto/dh/dh_key.c @@ -101,6 +101,7 @@ const DH_METHOD *DH_OpenSSL(void) static int generate_key(DH *dh) { int ok=0; + unsigned l; BN_CTX *ctx; BN_MONT_CTX *mont; BIGNUM *pub_key=NULL,*priv_key=NULL; @@ -112,9 +113,6 @@ static int generate_key(DH *dh) { priv_key=BN_new(); if (priv_key == NULL) goto err; - do - if (!BN_rand_range(priv_key, dh->p)) goto err; - while (BN_is_zero(priv_key)); } else priv_key=dh->priv_key; @@ -135,9 +133,15 @@ static int generate_key(DH *dh) } mont=(BN_MONT_CTX *)dh->method_mont_p; - if (!ENGINE_get_DH(dh->engine)->bn_mod_exp(dh, pub_key, dh->g, - priv_key,dh->p,ctx,mont)) - goto err; + l = dh->length ? dh->length : BN_num_bits(dh->p)-1; /* secret exponent length */ + + do + { + if (!BN_rand(priv_key, l, 0, 0)) goto err; + if (!ENGINE_get_DH(dh->engine)->bn_mod_exp(dh, pub_key, dh->g, + priv_key,dh->p,ctx,mont)) goto err; + } + while (BN_is_one(priv_key)); dh->pub_key=pub_key; dh->priv_key=priv_key; diff --git a/doc/crypto/DH_generate_key.pod b/doc/crypto/DH_generate_key.pod index 920995b2e5..d376dc9f2f 100644 --- a/doc/crypto/DH_generate_key.pod +++ b/doc/crypto/DH_generate_key.pod @@ -21,9 +21,8 @@ value to compute the shared key. DH_generate_key() expects B to contain the shared parameters Bp> and Bg>. It generates a random private DH value -unless Bpriv_key> is already set, and computes the -corresponding public value Bpub_key>, which can then be -published. +Bpriv_key>, and it computes the corresponding public value +Bpub_key>, which can then be published. DH_compute_key() computes the shared secret from the private DH value in B and the other party's public value in B and stores @@ -46,5 +45,7 @@ L, L, L, L DH_generate_key() and DH_compute_key() are available in all versions of SSLeay and OpenSSL. +Up to version 0.9.6b, DH_generate_key() would not generate a new +key if Bpriv_key> was already set. =cut -- 2.25.1