openssl/crypto/engine
Geoff Thorpe 9c5ed502ee This hooks the DH code into the engine framework in the same way that has
already been done for RSA. The others (DSA + RAND) will probably follow
in the near future too, but DH is easiest to test with RSA because one
can just force the use of the EDH cipher-suites.
2000-05-29 00:46:47 +00:00
..
vendor_defns Added Geoff's latest changes, which seems to mostly be DH stuff and a 2000-05-25 21:21:03 +00:00
engine.h Prevent calling code from doing the allocation of the ENGINE structure. 2000-05-26 15:21:47 +00:00
engine_err.c Add code and changes to implement the ENGINE mechanism. These are the 2000-05-25 19:55:54 +00:00
engine_int.h Add code and changes to implement the ENGINE mechanism. These are the 2000-05-25 19:55:54 +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 Prevent calling code from doing the allocation of the ENGINE structure. 2000-05-26 15:21:47 +00:00
engine_openssl.c This hooks the DH code into the engine framework in the same way that has 2000-05-29 00:46:47 +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_cswift.c Added Geoff's latest changes, which seems to mostly be DH stuff and a 2000-05-25 21:21:03 +00:00
Makefile.ssl Add code and changes to implement the ENGINE mechanism. These are the 2000-05-25 19:55:54 +00:00
README Added Geoff's latest changes, which seems to mostly be DH stuff and a 2000-05-25 21:21:03 +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 ...