openssl/crypto/engine
Richard Levitte cb9c5dc571 Merge from main, all conflicts resolved.
(I do this far too seldom...)
2000-07-12 16:34:34 +00:00
..
vendor_defns Cryptoswitch actually has a few more statuses than SW_OK. Let's provide the possibility for a better granularity in error checking 2000-06-30 15:52:07 +00:00
.cvsignore Get rid of those annoying "?"s from cvs update :-) 2000-06-26 13:36:04 +00:00
engine.h Some error checking when loading keys 2000-07-07 17:02:21 +00:00
engine_err.c Some error checking when loading keys 2000-07-07 17:02:21 +00:00
engine_int.h Add the possibility to load prvate and public keys from an engine and 2000-07-06 18:40:10 +00:00
engine_lib.c Some error checking when loading keys 2000-07-07 17:02:21 +00:00
engine_list.c Make it possible to turn off compilation of hardware support through 2000-06-30 11:02:02 +00:00
engine_openssl.c Add the possibility to load prvate and public keys from an engine and 2000-07-06 18:40:10 +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 Avoid the conflict between () and (void) 2000-07-12 15:14:12 +00:00
hw_cswift.c Avoid the conflict between () and (void) 2000-07-12 15:14:12 +00:00
hw_ncipher.c Avoid the conflict between () and (void) 2000-07-12 15:14:12 +00:00
Makefile.ssl Merge from main, all conflicts resolved. 2000-07-12 16:34:34 +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.