This made problems when used from OpenSSH.
[Lutz Jaenicke]
- *) 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
static int generate_key(DH *dh)
{
int ok=0;
+ int generate_new_key=0;
unsigned l;
BN_CTX ctx;
BN_MONT_CTX *mont;
{
priv_key=BN_new();
if (priv_key == NULL) goto err;
+ generate_new_key=1;
}
else
priv_key=dh->priv_key;
l = dh->length ? dh->length : BN_num_bits(dh->p)-1; /* secret exponent length */
- if (!BN_rand(priv_key, l, 0, 0)) goto err;
+ if (generate_new_key)
+ {
+ if (!BN_rand(priv_key, l, 0, 0)) goto err;
+ }
if (!dh->meth->bn_mod_exp(dh, pub_key,dh->g,priv_key,dh->p,&ctx,mont)) goto err;
dh->pub_key=pub_key;
DH_generate_key() expects B<dh> to contain the shared parameters
B<dh-E<gt>p> and B<dh-E<gt>g>. It generates a random private DH value
-B<dh-E<gt>priv_key>, and it computes the corresponding public value
-B<dh-E<gt>pub_key>, which can then be published.
+unless B<dh-E<gt>priv_key> is already set, and computes the
+corresponding public value B<dh-E<gt>pub_key>, which can then be
+published.
DH_compute_key() computes the shared secret from the private DH value
in B<dh> and the other party's public value in B<pub_key> and stores
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 B<dh-E<gt>priv_key> was already set.
=cut