Carlos;

You can certainly use the PKCS #11 interface-- just don't expect to get
the full benefit of your hardware accelerator.  This is what I found
with the Sun PCI Crypto card (basically an OEM Rainbow card):

This is the product that I've been looking at:

   http://www.sun.com/connectivity/suncryptoaccel1/

Sun P/N: X1133A

What I wanted to see was a rough-order comparison to what the card can
do for SSL session setup.  The test I used was an "SSL soak" tool that
negotiates an SSL connection, without session reuse, and then closes
it.  No requests, just an SSL open and close.

This is a worst-case scenario that is almost all RSA signing
operations (I used only RSA key pairs and certificates).

Here is what I recorded ("SSLs" are new SSL session negotiations,
"hosts" are number of simultaneous instances of SSLsoak, which is
single-threaded ):

Netra (2x296MHz CPUs) base, nes 4.1:

    ~27-32 SSLs/sec, 20 hosts

    SunOS wnpwp02 5.6 Generic_105181-23 sun4u    01/24/01

    14:06:49    %usr    %sys    %wio   %idle
    14:06:50      99       1       0       0
    14:06:51      96       4       0       0
    14:06:52      99       1       0       0
    14:06:53      99       1       0       0
    14:06:54      94       6       0       0

    Average       97       3       0       0

Netra (2x296MHz CPUs) w/ Crypto card, nes 4.1:

    ~72-73 SSLs/sec, 20 hosts

    SunOS wnpwp01 5.6 Generic_105181-23 sun4u    01/24/01

    12:55:29    %usr    %sys    %wio   %idle
    12:55:30      62      12       0      26
    12:55:31      67       7       0      26
    12:55:32      71       7       0      22
    12:55:33      67       6       0      27
    12:55:34      71      10       0      19

    Average       68       8       0      24

420R (2x450MHz CPUs) base, nes 4.1sp5:

    ~46/47 SSLs/sec, 20 hosts

    SunOS wnpwp06 5.6 Generic_105181-23 sun4u    01/24/01

    12:56:45    %usr    %sys    %wio   %idle
    12:56:46      97       3       0       0
    12:56:47      98       2       0       0
    12:56:48      97       3       0       0
    12:56:49      99       1       0       0
    12:56:50      94       6       0       0

    Average       97       3       0       0


Please note that I used the 420 to drive all the tests, except that
against the 420.  However, using a Netra to load the 420 gave the same
results as using Reddog, which is a 6-processor Ultra-Enterprise server.

As an interesting side, my HP LDPro desktop machine (2x200MHz Pentium
II) running Apache/mod_ssl under Linux 2.2.16 kernel, can support
about 40 SSLs/sec with 20 hosts.  I don't know whether this is because
of the FPU performance of the Pentium II vs. USparc-II, Linux
vs. Solaris, Apache vs. NES, or OpenSSL vs. Netscape Security
Services.  Just interesting.

I then compiled Apache 1.3 on the same box, and tried, again:

Apache 1.3.17, OpenSSL engine 0.9.6, mod_ssl 2.8.0:

 Netra (2x296MHz CPUs)

     ~175-200 SSLs/sec, 20 hosts

    SunOS wnpwp01 5.6 Generic_105181-23 sun4u    02/06/01

    13:20:36    %usr    %sys    %wio   %idle
    13:20:37      47      19       0      34
    13:20:38      50      17       0      33
    13:20:39      27      12       0      61
    13:20:40      30      20       6      44
    13:20:41      47      18       1      34
    13:20:42      48      22       0      31
    13:20:43      43      25       0      32
    13:20:44      30       8       0      62
    13:20:45      48      20       0      32
    13:20:46      46      21       0      34

    Average       42      18       1      40

And no, I didn't misplace a decimal point.  With
mod_ssl/openssl-engine, Apache rules.

The Rainbow card should have a theoretical maximum of 200 RSA
signings/second.  Apache/mod_ssl worked the card to the max; while NES
showed disappointing improvement.  What I was looking to see was the
effect on CPU load, this being one of our production system limitations.

So, why can't NES fully exercise the crypto hardware like Apache?  My
guess is the Java PKCS #11 interface.  Apache's mod_ssl interface is a
lot closer to the hardware than NES's PKCS #11 interface.  Still, an
approx. $1200 card made a Netra perform like a more expensive 420R. 
This is still comparing 2 CPU boxes, however-- I don't know if a 4 CPU
420 would scale linearly... I suspect not.

I'm interested in other's experiences with the same scenario.  Carlos,
please let me know how you make out.

I've also been looking at the nCipher external SCSI accelerators (which
I personally prefer).  Unfortunately, you can't buy these with little
"Sun" logos on them, so my provisioning organization is loathe to
purchase them.  We had been using the nCipher boxes with SGI hardware,
and they looked very promising, doing nearly 300 RSA signings/second.

                                Henry

Carlos Cid wrote:
> 
> Hello there,
> 
> We have been working on the development of a hardware accellerator to work
> with Netscape/iPlanet products and I have two questions :
> 
> 1) We have been able to hack NSS in order to make it use the functions we
> provide instead. In the early stages of development we wish to test it with
> iPlanet servers. Is it possible to "substitute" Netscape built-in NSS by
> ours ? We thought it would be a matter of relinking the libraries, but we
> were unable to find the original ones. And even if we can add our NSS to
> netscape (or iPlanet servers), how can we be sure that it is in fact using
> our libraries and not the native ones ?
> 
> 2) Our aim is to develop a PKCS#11 module for our product. Would we be able
> to obtain such module from NSS ? I mean, have only the PKCS#11 libraries
> "extracted" from NSS, without all the other stuff (or at least a base for
> the module), and then adding it as a PKCS#11 module to the server using
> modutil ? If yes, how ? Someone has already asked a similar question, but
> the answer was not very clear (it was just said that it was is possible).
> 
> Thanks a lot
> 
> Carlos

Reply via email to