Mark J. Cox [Wed, 3 Nov 1999 14:10:10 +0000 (14:10 +0000)]
Fix assembler for Alpha (tested only on DEC OSF not Linux or *BSD). The
problem was that one of the replacement routines had not been working since
SSLeay releases. For now the offending routine has been replaced with
non-optimised assembler. Even so, this now gives around 95% performance
improvement for 1024 bit RSA signs.
Bodo Möller [Tue, 26 Oct 1999 16:26:48 +0000 (16:26 +0000)]
Always hash the pid in the first iteration in ssleay_rand_bytes,
don't try to detect fork()s by looking at getpid().
The reason is that threads sharing the same memory can have different
PIDs; it's inefficient to run RAND_seed each time a different thread
calls RAND_bytes.
Bodo Möller [Tue, 26 Oct 1999 01:56:29 +0000 (01:56 +0000)]
Various randomness handling bugfixes and improvements --
some utilities that should have used RANDFILE did not,
and -rand handling was broken except in genrsa.
Bodo Möller [Thu, 14 Oct 1999 17:31:53 +0000 (17:31 +0000)]
Use of DEVRANDOM must be #ifdef'ed (the #ifdef was commented out
between SSLeay 0.8.1b and 0.9.0b with no apparent reason).
If we *want* an error when DEVRANDOM is not defined (it always is with
the current e_os.h) we should use #error.
Initial support for certificate purpose checking: this will
ultimately lead to certificate chain verification. It is
VERY EXPERIMENTAL at present though.
New option -dhparam to s_server to allow the DH parameter file to be set
explicitly. Previously it couldn't be changed because it was hard coded as
"server.pem".
Add support for public key input and output in rsa and dsa utilities with some
new DSA public key functions that were missing.
Also beginning of a cache for X509_EXTENSION structures: this will allow them
to be accessed more quickly for things like certificate chain verification...
Andy Polyakov [Sat, 11 Sep 1999 17:54:18 +0000 (17:54 +0000)]
Initial support for MacOS.
This will soon be complemented with MacOS specific source code files and
INSTALL.MacOS.
I (Andy) have decided to get rid of a number of #include <sys/types.h>.
I've verified it's ok (both by examining /usr/include/*.h and compiling)
on a number of Unix platforms. Unfortunately I don't have Windows box
to verify this on. I really appreciate if somebody could try to compile
it and contact me a.s.a.p. in case a problem occurs.
Submitted by: Roy Wood <roy@centricsystems.ca>
Reviewed by: Andy Polyakov <appro@fy.chalmers.se>
Bodo Möller [Thu, 9 Sep 1999 20:21:10 +0000 (20:21 +0000)]
Re-enable message about transition <foo.h> => <openssl/foo.h>
because various programs are not updated that often
and hence still expect header files names without the openssl/ prefix.
This is preliminary support for an "RSA null" cipher. Unfortunately when
OpenSSL is compiled with NO_RSA, no RSA operations can be used: including
key generation storage and display of RSA keys. Since these operations are
not covered by the RSA patent (my understanding is it only covers encrypt,
decrypt, sign and verify) they can be included: this is an often requested
feature, attempts to use the patented operations return an error code.
This is enabled by setting RSA_NULL. This means that if a particular application
has its own legal US RSA implementation then it can use that instead by setting
it as the default RSA method.
Still experimental and needs some fiddling of the other libraries so they have
some options that don't attempt to use RSA if it isn't allowed.
Andy Polyakov [Sun, 5 Sep 1999 14:17:42 +0000 (14:17 +0000)]
SHA clean-up Intel assembler companion.
I've chosen to nest two functions in order to save about 4K. As a result
s1-win32.asm doesn't look right (nested PROC/ENDP SEGMENT/ENDS) and it's
probably impossible to compile. I assume I have to reconsider... But not
today...
Andy Polyakov [Sun, 5 Sep 1999 12:42:04 +0000 (12:42 +0000)]
SHA clean-up and (LP64) tune-up.
"Clean-up" stands for the fact that it's using common message digest
template ../md32_common.h and sha[1_]dgst.c are reduced down to
'#define SHA_[01]' and then '#include "sha_locl.h"'. It stands "(LP64)"
there because it's 64 bit platforms which benefit most from the tune-up.
The updated code exhibits 40% performance improvement on IRIX64
(sounds too good, huh? I probably should double check if it's not
some cache trashing that was holding it back before), 28% - on
Alpha Linux and 12% - Solaris 7/64.