wbrawner/openssl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

The README for the engine code was quite out of date. Hopefully it is

Browse source 
now less so.
This commit is contained in:
Geoff Thorpe 2000-06-15 17:50:08 +00:00
parent aa23a57918
commit 6c62150674
1 changed files with 18 additions and 22 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

40
crypto/engine/README
View file

@ -1,19 +1,7 @@
NOTES, THOUGHTS, and EVERYTHING NOTES, THOUGHTS, and EVERYTHING
------------------------------- -------------------------------
(1) Maybe ENGINE_get_struct_size() isn't such a good idea. All ENGINEs (1) Concurrency and locking ... I made a change to the ENGINE_free code
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 because I spotted a potential hold-up in proceedings (doing too
much inside a lock including calling a callback), there may be much inside a lock including calling a callback), there may be
other bits like this. What do the speed/optimisation freaks think other bits like this. What do the speed/optimisation freaks think
@ -22,17 +10,25 @@ NOTES, THOUGHTS, and EVERYTHING
solid, but this manipulation is mostly (de)initialisation, I would solid, but this manipulation is mostly (de)initialisation, I would
think that most run-time locking is purely in the ENGINE_init and think that most run-time locking is purely in the ENGINE_init and
ENGINE_finish calls that might be made when getting handles for ENGINE_finish calls that might be made when getting handles for
RSA (and friends') structures, and these would be mostly reference RSA (and friends') structures. These would be mostly reference
count operations as the functional references should always be 1 count operations as the functional references should always be 1
or greater at run-time to prevent init/deinit thrashing. or greater at run-time to prevent init/deinit thrashing.
(3) Atalla isn't finished quite yet. (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.
(4) The DH stuff was added to the CryptoSwift code without testing (3) Of more concern, we need to work out (a) how to put together usable
because it should work trivially and didn't involve adding more of RAND_METHODs for units that just have one "get n or less random
the cropped bits from Rainbow's headers back into the vendor_defns bytes" function, (b) we also need to determine how to hook the code
stuff. (Also, randomness should be easy to add soon when I sort in crypto/rand/ to use the ENGINE defaults in a way similar to what
the headers out a bit more which would give hw_cswift a full has been done in crypto/rsa/, crypto/dsa/, etc.
suite).
(5) Another make update is probably due ... (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.