Geoff Thorpe wrote:
> 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.
Don't think I missed that at all.
This is one of those situations where you could build a multithreaded
API on top of an asynch API, or vice versa. Which one is right depends
on where you sit, and which fits the OS and hardware best.
Say, what do the existing crypto hardware devices provide in the
way of interfaces and synchronization? Where's the best place to find out
that kind of info? (The engine branch of OpenSSL will help, but it
might not use all the hooks available.)
> 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.
Yes, that would be the "OpenSSL way" of doing it.
> 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).
It's a viable approach, and one that fits OpenSSL's current paradigm.
But it's not an especially high throughput way of doing it. I bet the
way to get the most ops per second is to use a queued interface to the
hardware, not an interface where you submit one op and wait for it to
finish before you submit the next one.
> 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.
Eww. Sounds scary. Can you elaborate a bit more on that?
> > 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. :-)
Oh, sure. Be practical :-)
My API proposal was meant to generate discussion. I realize it's not an
especially practical direction to move OpenSSL in. Does the idea of
an event-driven SSL API appeal to anybody, at least in the abstract?
- Dan
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
