On 08/16/99, Dr Stephen Henson said:
>Just a quick check, you aren't in the US are you?
Yes, I am.
>Depends. RSA can be handled fairly cleanly. You can replace the high
>level PKCS#1 RSA functions or the lower level math operations. You can
>then install this as the default RSA method and RSA calls from then on
>get redirected to the other code.
Yes, this is exactly what was done -- but the point being that there's no way to do
that
in a generic fashion right now. You'd end up setting up an RSA structure with
appropriate
callbacks for each vendor.
>If you handle this right the application needs to call some function to
>initialise the default RSA method (hardware_init() say) and is otherwise
>unchanged.
>
>This can be done without changing the library at all.
This is what I'd done -- but again, it's not very expandable, and requires
lots of conditionals in the compile.
>Ideally it should have things like rsa_sign/rsa_verify callbacks too but
>the current system is usable.
It can definitely support those as well.
>Unfortunately analagous stuff can't be currently done with DSA or DH.
>What we should have is a DSA_METHOD and a DH_METHOD as well.
Agreed.
>If this thing is to be handled totally transparently then you'd probably
>need to have some way for OpenSSL to transparently load a shared lib
>cross platform.
Depends -- setting up a structure to contain information about the accelerator is
definitely an option. I can have a callback init method to go and dlsym() the
appropriate
functions in at runtime.
>Things like PKCS#11 don't allow this either.
First of all, how does PKCS #11 have any notion of whether or not something is
blocking? They
are apples and oranges. If the calling code expects that when a function returns,
some value
has returned with it, then it expects it to block until the result is ready. That is
entirely
the responsiblity of the calling code. My point is that the application and
nonblocking have
little to do with each other.
My primary interest here is in an SSL server where people don't want to use threads.
>Quite a few applications already follow the "one SSL connection per
>thread or process" model.
Possible, but this entirely discounts people who don't want to (or can't)
use threads. Async is more desirable in some cases.
>If I understand your suggestion you are saying that a more effective
>model would be to handle multiple SSL connections per thread or even
>just have a single thread with a select() loop.
Exactly -- something that can operate in async, without threads.
>My initial thought is that this could be tricky to handle. Would you be
>able to simultaneously select() on a group of fds and the hardware for
>example?
A way to accomplish what you're mentioning is via a small event system.
Some entries would need to be added to the SSL (or other) structures,
containing whether or not a hardware operation was pending. It'd operate
via a nonblocking event loop. I believe the hardware supports an
fd interface, so select() should work with both simultaneously.
>Well it does have a notion of hardware keys. Again this is only handled
>with RSA. RSA keys can have separate methods. A typical smart card
>application might load the public key components into an RSA structure
>and redirect rsa_mod_exp to the card while keeping the rest in software.
>This needed a few kludges before OpenSSL 0.9.4 but it is a bit cleaner
>now.
>
>What is doesn't have a notion of is how to "load" the keys. This needs
>some kind of key database API. If this is handled properly then an
>application should be able to "load" a key from, say PKCS#11, a PKCS#12
>file, the current stuff like PEM files or anything else and not notice
>any difference except (possibly) it can't access the private key
>components.
It doesn't understand the idea that it might need to perform an operation
via a key that it cannot see. For example, if one needed to perform a
verify against a secure key that was stored in hardware, how would you
do this (keeping in mind of course that the key CANNOT leave the
hardware)? One way is to make it so that the methods always call out
to hardware, but that's not very general purpose.
Another way is for keys to contain the notion of whether or not they
are opaque. So in the case of an opaque key, it could be referred to
by hash, and when the time came to perform an operation, OpenSSL would
see that this was an opaque key and call out the hardware to perform
the operations.
The key loading is pretty trivial in relative terms, it's only a matter
of getting keys in and out of the hardware and into the formats that
OpenSSL requires. But in a lot of cases, you don't want the keys
ever leaving the hardware.
--Chris
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
