After my first round of adding nCipher support to SSLeay, I'm going to start
working on a new hardware API for OpenSSL.
I already have some ideas about what kinds of things I want to do, but I'd like
some feedback from others.
Some potential issues I see with OpenSSL:
(1) Completely lacks any sort of hardware API
When I added the nCipher support, it basically ammounted to some stub code interfaces
from
the guys at nCipher, and then providing callbacks for each library function that I
wanted
done in hardware (RNG, mod_exp/mod_exp_crt, etc.) While this was fine for a once off
type
of deal, it wouldn't work very well at all as support for different or new hardware is
desired. Plus it means that the codebase becomes littered with platform specific
calls.
(2) Doesn't have the capability internally to support calls out to hardware in a
nonblocking fashion
The hardware from nCipher at least, is very parallel internally, and is designed to
efficiently
support a large number of simultaneous transactions. The initial latency from
submission to
receipt can be high in relative terms. With my rev1 for SSLeay, the only way to
really see the
benefit of hardware is to use a large thread pool, and have a thread per
SSL_connect()/accept().
As an example metric, a (we'll say non-optimized for the purpose of discussion) server
running
on an UltraSPARC will quickly get the CPU pegged if it's being hammered with SSL
connections.
When the nCipher hardware is employed, the machine will be able to handle just about
as many
connections as you could reasonably throw at it, and remain at between 25%-30% CPU
utilization,
with most of that time spent in I/O wait. The problem with this is that the actual
connection
latency is higher than without hardware, because of the time it takes to get data in
and out
of the accelerator. But by submitting several requests simultaneously, the hardware
can be
taken good advantage of.
The hardware itself can support asynchronous submits via an interface that's rougly
analagous
to select(), but OpenSSL currently doesn't support a return for functions that's
analagous to
EAGAIN. That's something that would need to be added. Even though I didn't think it
was so
terrible when I first did it, I think the idea of forcing people to use threads to
obtain
decent performance is unacceptable.
I've been looking over the codebase to see how this would need to be accomplished.
It's
definitely not a trivial task, but a managable one.
(3) Doesn't understand the notion of a key that it cannot see
Hardware key management is (arguably) much more insecure if the keys are taken down
out of
the "secure" hardware for operations. Ideally, OpenSSL would perform the
encrypt/decrypt
operations, and be totally oblivious to whether *it* actually did them or not. If that
statement confuses anyone, just think of the callback interfaces. The library has no
way
of knowing what the callback functions are actually doing, it just expects that when
it
makes the call, it gets back what it was expecting. I am thinking of trying something
similar in terms of how keys are dealt with.
Any opinions, additions, or thoughts on this are welcome.
--Chris
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
