Commit graph

32 commits

Author SHA1 Message Date
Richard Levitte
3257904c56 It makes much more sense and is much more consistent with the rest of
OpenSSL to have to opt out hardware support instead of having to opt
it in.  And since the hardware support modules are self-contained and
actually check that the vendor stuff is loadable, it still works as
expected, or at least, so I think...
2000-06-29 21:20:14 +00:00
Richard Levitte
2a7619d762 Give the programmer of extra engines the possibility to actually make
it functional :-).
2000-06-29 16:33:59 +00:00
Richard Levitte
70d03c4f59 Make the use of logstream thread-safe. 2000-06-29 16:32:34 +00:00
Richard Levitte
d813a428a7 When closing the hwcrhk engine, also remove the reference to the
logstream.
2000-06-29 16:16:50 +00:00
Richard Levitte
3b2972d8d9 Add the possibility to control some engine internals. 2000-06-29 14:26:07 +00:00
Richard Levitte
2165d91196 Rename 'hwcrhk' to 'ncipher' in all public symbols. Redo the logging function so it takes a BIO. Make module-local functions static 2000-06-29 13:00:07 +00:00
Richard Levitte
fc99c92835 The error ENGINE_R_HWCRYPTOHOOK_REPORTS should never have been used 2000-06-29 12:58:52 +00:00
Richard Levitte
1dde74f229 Rename 'hwcrhk' to 'ncipher' in all public symbols 2000-06-26 23:15:16 +00:00
Geoff Thorpe
665b5ab5a7 Strange how one line can make a world of difference, particularly when
the one line turns an error return value into a success return value.
:-) "openssl speed -engine hwcrhk rsa1024" now passes through ok.
2000-06-26 15:58:33 +00:00
Geoff Thorpe
13232559fc Get rid of those annoying "?"s from cvs update :-) 2000-06-26 13:36:04 +00:00
Geoff Thorpe
d32e8acf08 Now that the branch has been updated with the DSO changes in the head,
correct the DSO-dependant code in the engine code.
2000-06-20 13:59:48 +00:00
Richard Levitte
b215f70a0e Merge of stuff from main trunk, all conflicts resolved, and addition
of dynamic lock support in the nCipher code.
2000-06-19 17:28:22 +00:00
Richard Levitte
7ed20a2158 Merge of stuff from main trunk, all conflicts resolved. 2000-06-19 14:44:57 +00:00
Geoff Thorpe
6c62150674 The README for the engine code was quite out of date. Hopefully it is
now less so.
2000-06-15 17:50:08 +00:00
Geoff Thorpe
aa23a57918 (1) In the atalla initialisation, use the test from Ben's earlier
Atalla code to see if the accelerator is running.
(2) Turn some spaces into tabs.
2000-06-15 17:32:42 +00:00
Geoff Thorpe
8e2c277353 Ah, ok so my problem had been typographical rather than philosophical.
It's cute to observe that Atalla having no RSA-specific form of mod_exp
causes a DSA server to achieve about 6 times as many signatures per
second than an RSA server. :-)
2000-06-15 17:14:45 +00:00
Geoff Thorpe
f18ef82a9f Little typo. 2000-06-14 17:54:28 +00:00
Geoff Thorpe
cc015c48db This adds Atalla support code to the ENGINE framework. If you have an
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.
2000-06-14 17:04:10 +00:00
Richard Levitte
9a4051050c Geoff inspired me to nullify some pointers if initialisation went
wrong.  Additionally, just give a new value to hndidx once.
2000-06-14 16:57:57 +00:00
Geoff Thorpe
4c4ea428cc DSO_bind() is effectively a method-specific wrapper for dlopen() or
whatever the underlying API is. It must return (void *) because shared
libraries can expose functions, structures, or whatever. However, some
compilers give loads of warnings about casted function pointers through
this code, so I am explicitly casting them to the right prototypes.
2000-06-14 14:28:16 +00:00
Geoff Thorpe
f812743544 If initialisation fails for any reason, the global function pointers
should be NULL'd out.
2000-06-14 13:24:37 +00:00
Geoff Thorpe
87f3435f78 This hooks the "hwcrhk" engine Richard just submitted into the default
engine list if HW_NCIPHER is defined. I want to play :-)
2000-06-13 18:11:38 +00:00
Richard Levitte
86787f93d6 - merged in the latest from the main trunk, fixed all conflicts
- implemented nCipher support via the nfhwcrhk library (not well tested).
- make update + make depend
2000-06-13 16:21:06 +00:00
Geoff Thorpe
05d909c549 * Migrate the engine code's Malloc + Free calls to the newer
OPENSSL_malloc and OPENSSL_free.

* 3 "normal" files (crypto/rsa/rsa_lib.c, crypto/dsa/dsa_lib.c
  and crypto/dh/dh_lib.c) had their Malloc's and Free's missed
  when Richard merged the changes across to this branch -
  probably because those files have been changed in this branch
  and gave some grief to the merge - so I've changed them
  manually here.
2000-06-09 11:42:02 +00:00
Geoff Thorpe
96d7e0ece7 This adds DSA signature verification to the CryptoSwift support. 2000-05-29 13:01:34 +00:00
Geoff Thorpe
835475a2d6 Tie DSA into the engine framework as with RSA and DH so far. I've verified
this integration with a web-server using CryptoSwift engine code with RSA
and DSA certificates (and with EDH cipher suites).
2000-05-29 11:07:38 +00:00
Geoff Thorpe
a26f2b5e62 General tidy up of existing code, and add first half of DSA support for
CryptoSwift (this currently only does signing, verification will be
hooked in shortly).
2000-05-29 10:59:46 +00:00
Geoff Thorpe
9c5ed502ee This hooks the DH code into the engine framework in the same way that has
already been done for RSA. The others (DSA + RAND) will probably follow
in the near future too, but DH is easiest to test with RSA because one
can just force the use of the EDH cipher-suites.
2000-05-29 00:46:47 +00:00
Geoff Thorpe
bb51f21728 Update the test program to compile and run with the changes I just made
to ENGINE_new (and ENGINE_get_struct_size).
2000-05-26 15:43:28 +00:00
Geoff Thorpe
0e0e569cbf Prevent calling code from doing the allocation of the ENGINE structure.
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.
2000-05-26 15:21:47 +00:00
Richard Levitte
71c8e9f1c3 Added Geoff's latest changes, which seems to mostly be DH stuff and a
README.  Oh, and a test program.
2000-05-25 21:21:03 +00:00
Richard Levitte
e759b095d4 Add code and changes to implement the ENGINE mechanism. These are the
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!
2000-05-25 19:55:54 +00:00