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
..

NOTES, THOUGHTS, and EVERYTHING
-------------------------------

(1) Maybe ENGINE_get_struct_size() isn't such a good idea. All ENGINEs
    should be allocated from within OpenSSL (rather than, for example,
    a loaded DSO). Two reasons, (i) DSOs authors are likely to stash
    the return value as an assumed constant and so everything will
    break down horribly when OpenSSL is changed/expanded, (ii) with
    the structure allocated within OpenSSL, we could handle the case
    where a DSO *really* wants to close down and lick its wounds even
    if there are still references because we could simply NULL out the
    pointers in the structure. If I change this, I should also
    remember to get rid of the parameter in ENGINE_new() as it would
    serve no purpose and is likely to confuse.

(2) Concurrency and locking ... I made a change to the ENGINE_free code
    because I spotted a potential hold-up in proceedings (doing too
    much inside a lock including calling a callback), there may be
    other bits like this. What do the speed/optimisation freaks think
    of this aspect of the code and design? There's lots of locking for
    manipulation functions and I need that to keep things nice and
    solid, but this manipulation is mostly (de)initialisation, I would
    think that most run-time locking is purely in the ENGINE_init and
    ENGINE_finish calls that might be made when getting handles for
    RSA (and friends') structures, and these would be mostly reference
    count operations as the functional references should always be 1
    or greater at run-time to prevent init/deinit thrashing.

(3) Atalla isn't finished quite yet.

(4) The DH stuff was added to the CryptoSwift code without testing
    because it should work trivially and didn't involve adding more of
    the cropped bits from Rainbow's headers back into the vendor_defns
    stuff. (Also, randomness should be easy to add soon when I sort
    the headers out a bit more which would give hw_cswift a full
    suite).

(5) Another make update is probably due ...