Changes between 0.9.6 and 0.9.7 [xx XXX 2001]
- Both OpenSSL 0.9.6a (bugfix release, 5 Apr 2001) and OpenSSL 0.9.7
- are based on OpenSSL 0.9.6.
+ OpenSSL 0.9.6a/0.9.6b (bugfix releases, 5 Apr 2001 and 9 July 2001)
+ and OpenSSL 0.9.7 were developped in parallel, based on OpenSSL 0.9.6.
+
Change log entries are tagged as follows:
- -) applies to 0.9.6a (/0.9.6b) only
- *) applies to 0.9.6a (/0.9.6b) and 0.9.7
+ -) applies to 0.9.6a/0.9.6b/0.9.6c only
+ *) applies to 0.9.6a/0.9.6b/0.9.6c and 0.9.7
+) applies to 0.9.7 only
+ +) Initial reduction of linker bloat: the use of some functions, such as
+ PEM causes large amounts of unused functions to be linked in due to
+ poor organisation. For example pem_all.c contains every PEM function
+ which has a knock on effect of linking in large amounts of (unused)
+ ASN1 code. Grouping together similar functions and splitting unrelated
+ functions prevents this.
+ [Steve Henson]
+
+ *) Initialize static variable in crypto/dsa/dsa_lib.c and crypto/dh/dh_lib.c
+ explicitely to NULL, as at least on Solaris 8 this seems not always to be
+ done automatically (in contradiction to the requirements of the C
+ standard). This made problems when used from OpenSSH.
+ [Lutz Jaenicke]
+
+ *) 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
+ RSA_eay_private_decrypt
+ RSA_eay_private_encrypt (signing)
+ RSA_eay_public_decrypt (signature verification)
+
+ (default implementations for RSA_public_encrypt,
+ RSA_private_decrypt, RSA_private_encrypt, RSA_public_decrypt),
+ always reject numbers >= n.
+ [Bodo Moeller]
+
+ *) In crypto/rand/md_rand.c, use a new short-time lock CRYPTO_LOCK_RAND2
+ to synchronize access to 'locking_thread'. This is necessary on
+ systems where access to 'locking_thread' (an 'unsigned long'
+ variable) is not atomic.
+ [Bodo Moeller]
+
+ *) In crypto/rand/md_rand.c, set 'locking_thread' to current thread's ID
+ *before* setting the 'crypto_lock_rand' flag. The previous code had
+ a race condition if 0 is a valid thread ID.
+ [Travis Vitek <vitek@roguewave.com>]
+
+ +) Cleanup of EVP macros.
+ [Ben Laurie]
+
+ +) Change historical references to {NID,SN,LN}_des_ede and ede3 to add the
+ correct _ecb suffix.
+ [Ben Laurie]
+
+ +) Add initial OCSP responder support to ocsp application. The
+ revocation information is handled using the text based index
+ use by the ca application. The responder can either handle
+ requests generated internally, supplied in files (for example
+ via a CGI script) or using an internal minimal server.
+ [Steve Henson]
+
+ +) Add configuration choices to get zlib compression for TLS.
+ [Richard Levitte]
+
+ +) Changes to Kerberos SSL for RFC 2712 compliance:
+ 1. Implemented real KerberosWrapper, instead of just using
+ KRB5 AP_REQ message. [Thanks to Simon Wilkinson <sxw@sxw.org.uk>]
+ 2. Implemented optional authenticator field of KerberosWrapper.
+
+ Added openssl-style ASN.1 macros for Kerberos ticket, ap_req,
+ and authenticator structs; see crypto/krb5/.
+
+ Generalized Kerberos calls to support multiple Kerberos libraries.
+ [Vern Staats <staatsvr@asc.hpc.mil>,
+ Jeffrey Altman <jaltman@columbia.edu>
+ via Richard Levitte]
+
+ +) Cause 'openssl speed' to use fully hard-coded DSA keys as it
+ already does with RSA. testdsa.h now has 'priv_key/pub_key'
+ values for each of the key sizes rather than having just
+ parameters (and 'speed' generating keys each time).
+ [Geoff Thorpe]
+
+ -) OpenSSL 0.9.6b released [9 July 2001]
+
+ *) Change ssleay_rand_bytes (crypto/rand/md_rand.c)
+ to avoid a SSLeay/OpenSSL PRNG weakness pointed out by
+ Markku-Juhani O. Saarinen <markku-juhani.saarinen@nokia.com>:
+ PRNG state recovery was possible based on the output of
+ one PRNG request appropriately sized to gain knowledge on
+ 'md' followed by enough consecutive 1-byte PRNG requests
+ to traverse all of 'state'.
+
+ 1. When updating 'md_local' (the current thread's copy of 'md')
+ during PRNG output generation, hash all of the previous
+ 'md_local' value, not just the half used for PRNG output.
+
+ 2. Make the number of bytes from 'state' included into the hash
+ independent from the number of PRNG bytes requested.
+
+ The first measure alone would be sufficient to avoid
+ Markku-Juhani's attack. (Actually it had never occurred
+ to me that the half of 'md_local' used for chaining was the
+ half from which PRNG output bytes were taken -- I had always
+ assumed that the secret half would be used.) The second
+ measure makes sure that additional data from 'state' is never
+ mixed into 'md_local' in small portions; this heuristically
+ further strengthens the PRNG.
+ [Bodo Moeller]
+
+) Speed up EVP routines.
Before:
encrypt