Having a crypto API (pkcs11?) within the product would be very welcome.
Personally, I think only asymmetric private key operations should be
performed in hardware and symmetric key operation would be performed as
they are now. This is because some applications would use smart cards
which normally are CPU impaired. If the hardware 'accelerates' symmetric
key operations then perhaps this could be enabled at compile time or run
time.
Ron.
> -----Original Message-----
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, August 14, 1999 12:28 AM
> To: [EMAIL PROTECTED]
> Subject: Revised OpenSSL hardware support
>
> 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]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
