34 lines
1.9 KiB
Text
34 lines
1.9 KiB
Text
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.
|