1. rnd_reference was a duplication of the work the the engine
framework does, and wasn't ever checked. Removed.
2. use the NO_ macros to disable appropriate algorithms.
3. Only implement the RNG stuff if AEPRAND is defined (default: not
defined, because the AEP people plan on having boards without it.
I'll see if I can device a more dynamic way of disabling this).
4. aep_finish() now closes all connections, and if that worked, does a
proper finalize.
5. proper AEP types are used to conform to the AEP definitions of
their own functions.
6. remake the use of thread locks. The use of CRYPTO_LOCK_DYNLOCK was
definitely inappropriate, and for random generator stuff, it's
better to use CRYPTO_LOCK_RAND.
Also, I applied certain changes that were provided by the AEP people.
Among others, BN_CTX_new() is not used to initialise a BN context
(this was never done before, and may have made things slower or not
working at all.
1. some platforms do not have inttypes.h, and chasing them down
becomes ridiculous. Therefore, uint64_t can't be used for 64-bit
values.
2. some (other) platforms do not support "long long".
Solution: make AEP_U64 a struct with two longs unless long already is
64 bit long.
Also, restore all other types back to use unsigned char, unsigned int
and unsigned long. Make sure that AEP_U32 actually becomes 32 bits,
even on platforms where long is 64 bits (actually, we're just guessing
that int will stay at 32 bits on those...).
32-bit platforms. Instead, make use of inttypes.h and use the types
defined there to get 8-, 16-, 32- an 64-bit values.
There might be some operating systems where one should use int_types.h
instead of inttypes.h. Unfortunately, I don't recall which one(s).
patches taken from Red Hat Linux 7.2. Original code from Broadcom with
patches and backport by Nalin, more backport to fix warnings and const
changes by Mark
Submitted by: Mark Cox
Reviewed by:
PR:
for acceleration only at the moment, but full key management is being
worked on for the future. This code has been compiled cross-platform but
not extensively tested
Submitted by: Mark Cox, Baltimore Technologies
Reviewed by: Mark Cox
PR:
sure they are available in opensslconf.h, by giving them names starting
with "OPENSSL_" to avoid conflicts with other packages and by making
sure e_os2.h will cover all platform-specific cases together with
opensslconf.h.
I've checked fairly well that nothing breaks with this (apart from
external software that will adapt if they have used something like
NO_KRB5), but I can't guarantee it completely, so a review of this
change would be a good thing.
BCM5805 and BCM5820 units. So far I've merely taken a skim over the code
and changed a few things from their original contributed source
(de-shadowing variables, removing variables from the header, and
re-constifying some functions to remove warnings). If this gives
compilation problems on any system, please let me know. We will hopefully
know for sure whether this actually functions on a system with the relevant
hardware in a day or two. :-)
Atalla card, you should be able to compile with the "hw-atalla" switch
with "./config" or "perl Configure", and then you can use the command-
line switch "-engine atalla" inside speed, s_cient and s_server (after
checking out note (1)).
Notes:
(1) I've turned on native name translation when loading the shared-
library, but this means that the Unix shared library needs to be
libatasi.so rather than atasi.so. I got around this in my testing
by creating a symbollic link from /usr/lib/libatasi.so to the real
library, but something better will be needed. It also assumes in
win32 that the DLL will be called atasi.dll - but as I don't have
a win32/atalla environment to try I have no idea yet if this is
the case.
(2) Currently DSA verifies are not accelerated because I haven't yet
got a mod_exp-based variant of BN_mod_exp2_mont() that yields
correct results.
(3) Currently the "init()" doesn't fail if the shared library can
load successfully but the card is not operational. In this case,
the ENGINE_init() call will succeed, but all RSA, DSA, DH, and
the two BN_*** operations will fail until the ENGINE is switched
back to something that does work. I expect to correct this next.
(4) Although the API for the Atalla card just has the one crypto
function suggesting an RSA private key operation - this is in
fact just a straight mod_exp function that ignores all the RSA
key parameters except the (private) exponent and modulus. This is
why the only accelerator work is taking place inside the mod_exp
function and there's no optimisation of RSA private key operations
based on CRT etc.
patches that Geoff had in a patch file in his play directory.
NOTE for openssl-cvs: THIS IS A CVS BRANCH (BRANCH_engine). IT IS
NOT FOR THE FAINTHEARTED TO PLAY WITH. The code works as it is, but
it's not at all sure it ends up in the OpenSSL distributio in this
form, so do not get dependent on it!
Those rsyncing the repository are considered warned!
