openssl/crypto/engine
2000-06-15 17:50:08 +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
engine.h This adds Atalla support code to the ENGINE framework. If you have an 2000-06-14 17:04:10 +00:00
engine_err.c This adds Atalla support code to the ENGINE framework. If you have an 2000-06-14 17:04:10 +00:00
engine_int.h This adds Atalla support code to the ENGINE framework. If you have an 2000-06-14 17:04:10 +00:00
engine_lib.c Added Geoff's latest changes, which seems to mostly be DH stuff and a 2000-05-25 21:21:03 +00:00
engine_list.c This adds Atalla support code to the ENGINE framework. If you have an 2000-06-14 17:04:10 +00:00
engine_openssl.c Tie DSA into the engine framework as with RSA and DH so far. I've verified 2000-05-29 11:07:38 +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 (1) In the atalla initialisation, use the test from Ben's earlier 2000-06-15 17:32:42 +00:00
hw_cswift.c DSO_bind() is effectively a method-specific wrapper for dlopen() or 2000-06-14 14:28:16 +00:00
hw_ncipher.c Little typo. 2000-06-14 17:54:28 +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.