initialised for use, but one of the useful things about ENGINE_ctrl()
is that it can be a useful way to provide settings that should be
used during initialisation. Instead, I've altered the code to insist
that the engine has a valid *structural* reference (rather than a
*functional* one).
(a) a couple of typos in the source code
(b) adds a ctrl command and handling code to enable or disable the fork()
checking that CHIL can do when applications are calling fork() in
their application and using the library from multiple child processes
after the one initialisation.
(c) adds another ctrl command to prevent the initialisation of the CHIL
library from providing mutex-handling callbacks, even if the library
has suitable callbacks already available. This can simplify (and
optimise) applications that do not use multi-threading.
implement it for nCipher hardware. The interface in itself should be
clear enough, but the nCipher implementation is currently not the
best when it comes to getting a passphrase from the user. However,
getting it better is a little hard until a better user interaction
method is create.
Also, use the possibility in req, so we can start to create CSR's with
keys from the nForce box.
WARNING: I've made *no* tests yet, mostly because I didn't implement
this on the machine where I have an nForce box to play with. All I
know is that it compiles cleanly on Linux...
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.
This was a bad idea in the first place, in particular it would have made
it trickier to implement error-handling, particularly when shutting down
third-party shared libraries 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!
