On Tue, 14 Nov 2000, Dan Kegel wrote:
> I don't think we need nonblocking crypto; it would be enough to be able
> to shunt the crypto off into another thread. That's what my API proposal
> was about.
I think that misses the entire point of why a form of async public-key
crypto might be advantageous. What if the problem trying to be solved is
that the crypto is being performed somewhere else? (be it in a smart card,
accelerator device, or across the room on another machine). This can mean
wherever the latency is high(ish) but involves virtually no local
overhead. The point then is to make it possible to "start" key operations
and query for completion as a seperate function call. Once you've done
that - if you want to implement [RSA|DSA|DH]_METHODs that actually
dispatch the operations off to a dedicated thread/process then that is but
one application of this.
The biggest argument for all this, IMHO, is that currently the only
practical task inside the SSL state-machine that can stop an SSL_read() or
SSL_write() returned "immediately" (for some suitable definition of
"immediate" <grin>) is a public key operation. If it were possible for
public key ops to support an async interface, then the SSL state machine
could be adjusted for this and SSL_read/SSL_write would be able to be used
in applications with much slicker requirements. Ie. where it is required
that these functions return within some reasonable time-frame irrespective
of where the state-machine is at. Public-key ops create a problem in that
regard. If it is possible to code the SSL state machine to cope with
non-blocking IO on its encrypted streams, then it is certainly possible to
make it cope with a single new state that won't budge until the
async_public_key_op_query() returns ASYNC_OP_FINISHED.
Virtually any other real-world application that involves intensive
operations supports this concept - SQL database APIs being a classic
example. I posted an idea of how this could be done in a clean backwards
compatible manner that didn't make architectural assumptions about
where/how this would be used. At least, a lot less assumptions than are
made by assuming this would happen over BIOs, at the SSL layer itself, or
only as a way to support multi-tasking (because async public key ops can
be useful in a single-process single-thread model too if the operations
themselves are done on a different system altogether).
After posting that, I thrashed it out a little further with Steve Henson -
the idea that came up is that the public key METHODs could not only expose
to the caller if they support an async interface, but could also allow the
caller to discover at run-time if they support select()able file
descriptors, or thread/window messages (win32), or any other technique for
notification that operations are complete. Notification is *not* required
for this to be usable, but may be preferable in the calling application -
so the caller could check these capabilities too before electing whether
to switch the async support on or not.
> But why would you want to? The whole point of my API was to reduce
> the complexity of the innards of OpenSSL, and to make it easy to
> shunt crypto stuff off to another thread. Implementing my API on
> top of the current OpenSSL API would be absurd.
Well, whilst reasonable opportunties still exist to work with the existing
API, I prefer to explore those. For now at least. :-)
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
