openssl/crypto/engine
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
..
vendor_defns This adds Atalla support code to the ENGINE framework. If you have an 2000-06-14 17:04:10 +00:00
.cvsignore Get rid of those annoying "?"s from cvs update :-) 2000-06-26 13:36:04 +00:00
engine.h Give the programmer of extra engines the possibility to actually make 2000-06-29 16:33:59 +00:00
engine_err.c Give the programmer of extra engines the possibility to actually make 2000-06-29 16:33:59 +00:00
engine_int.h It makes much more sense and is much more consistent with the rest of 2000-06-29 21:20:14 +00:00
engine_lib.c Add the possibility to control some engine internals. 2000-06-29 14:26:07 +00:00
engine_list.c It makes much more sense and is much more consistent with the rest of 2000-06-29 21:20:14 +00:00
engine_openssl.c Add the possibility to control some engine internals. 2000-06-29 14:26:07 +00:00
enginetest.c Update the test program to compile and run with the changes I just made 2000-05-26 15:43:28 +00:00
hw_atalla.c It makes much more sense and is much more consistent with the rest of 2000-06-29 21:20:14 +00:00
hw_cswift.c It makes much more sense and is much more consistent with the rest of 2000-06-29 21:20:14 +00:00
hw_ncipher.c It makes much more sense and is much more consistent with the rest of 2000-06-29 21:20:14 +00:00
Makefile.ssl This adds Atalla support code to the ENGINE framework. If you have an 2000-06-14 17:04:10 +00:00
README The README for the engine code was quite out of date. Hopefully it is 2000-06-15 17:50:08 +00:00

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

(1) 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. 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.

(2) nCipher support, via the HWCryptoHook API, is now in the code.
    Apparently this hasn't been tested too much yet, but it looks
    good. :-) Atalla support has been added too, but shares a lot in
    common with Ben's original hooks in bn_exp.c (although it has been
    ENGINE-ified, and error handling wrapped around it) and it's also
    had some low-volume testing, so it should be usable.

(3) Of more concern, we need to work out (a) how to put together usable
    RAND_METHODs for units that just have one "get n or less random
    bytes" function, (b) we also need to determine how to hook the code
    in crypto/rand/ to use the ENGINE defaults in a way similar to what
    has been done in crypto/rsa/, crypto/dsa/, etc.

(4) ENGINE should really grow to encompass more than 3 public key
    algorithms and randomness gathering. The structure/data level of
    the engine code is hidden from code outside the crypto/engine/
    directory so change shouldn't be too viral. More important though
    is how things should evolve ... this needs thought and discussion.