9 Commits

Author SHA1 Message Date
Richard Levitte
dcd4d341e1 Since C compilers on VMS (perhaps with gcc being the great exception)
do not quite follow the same rules as on Unix, we need to use the
FLAT_INC tweak to include the vendor-specific header files.
2000-09-09 07:14:43 +00:00
Richard Levitte
a6f8bbcad9 Avoid the conflict between () and (void) 2000-07-12 15:14:12 +00:00
Richard Levitte
64c4f5732d Add the possibility to load prvate and public keys from an engine and
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...
2000-07-06 18:40:10 +00:00
Richard Levitte
ae02fc5348 Make it possible to turn off compilation of hardware support through
the configuration parameter 'no-hw'.
2000-06-30 11:02:02 +00:00
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
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
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
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