259896 - Make rsaperf use PKCS#11

Status: RESOLVED FIXED

(NSS :: Tools, enhancement, P2)

Description

[Julien Pierre]

Currently, rsaperf links statically to freebl, and thus can only test the RSA
performance of our mpi library. Also, it is hardcoded to a 1024 bit RSA key size.

It would be very useful for it to be able to test the RSA performance of other
PKCS#11 tokens, as well as different key sizes.

Since a cert is already specified, the token to use for the operation could be
determined by the token/nickname string; and the key size could be the key size
of the private key that matches that cert, rather than a conversion of that key
to 1024 bits.

It may be valuable to keep the mpi mode as an option, in order to evaluate the
PKCS#11 interface overhead.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

IIRC, the original rsaperf test program hard coded the test key, 
not just the key size, but the whole key.  
This was to ensure that comparisons were measuring ONLY differences in the
implementation, and NOT differences due to the number of 1 bits in the 
exponent.  
IMO, the ability to control the exact private key used in the test is an 
important part of the test, regardless of which  API is being tested.
And, yes, I'd like to see the ability to test only the BLAPI API be preserved.

I have no objections to adding the ability to test other APIs also.
But we should make every effort to ensure that we are comparing apples to apples.

Comment 2

[Robert Relyea]

Unless the token is a FIP's token, there should be no problem using
C_CreateObject to import the private key (there are also PK11Wrapper calls to do
this as well).

I see no problem parameterizing the key size, though as nelson suggested, the
test should use a fixed key (In this case you could have fixed 1024 2048 and
4096 keys for instance). Of course you would only compare the performance of
like keys.

bob

Comment 3

[Julien Pierre]

I found that the nickname argument is only used to decide whether to initialize
NSS or not. But NSS doesn't actually get used. There is a whole bunch of code
that used NSS which is now ifdef'ed out.
The public and private keys used are currently hardcoded .

The changes needed are :

- allow rsaperf to use private keys through PKCS#11, using the nickname passed
in . Should we use that as a key nickname, or as a cert nickname to find the
corresponding private key ?

Either way, I need to write two callback functions that take a SECKEYPrivateKey*
and SECKEYPublicKey* to do public and private RSA operations.

This will allow using persistent (token) keys of any size .

- add a way to import our hardcoded keys as session object into a specified slot 

- allow keygen of a specified size

- add hardcoded keys of different sizes : 512, 2048, 4096 bits

Comment 4

[Julien Pierre]

Attachment: preliminary patch

This patch implements most of the features I described.
It's missing :
- keygen with freebl (works with PKCS#11)
- import of our hardcoded 1024 keypair to PKCS#11
- hardcoded keys other 1024 bits

It's capable of testing RSA public or private keys of any size if they are
stored as token objects, or as session objects with a keygen.

Here are some private key op results on an opteron with various keysizes using
PKCS#11 session objects :

[jp96085@nss-amd-solaris]/h/monstre/export/home/tip/mozilla/dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/bin
113 % ./rsaperf -d . -s -p 5 -g -h "NSS Generic Crypto Services" -k 512


Generating RSA key.  This may take a few moments...

Using PKCS#11 with temporary 512 bits key in token NSS Generic Crypto Services.

20669 iterations in 5 seconds
4133.70 operations/s .
one operation every 241 microseconds
[jp96085@nss-amd-solaris]/h/monstre/export/home/tip/mozilla/dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/bin
114 % ./rsaperf -d . -s -p 5 -g -h "NSS Generic Crypto Services" -k 1024


Generating RSA key.  This may take a few moments...

Using PKCS#11 with temporary 1024 bits key in token NSS Generic Crypto
Services.
5782 iterations in 5 seconds
1156.24 operations/s .
one operation every 864 microseconds
[jp96085@nss-amd-solaris]/h/monstre/export/home/tip/mozilla/dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/bin
115 % ./rsaperf -d . -s -p 5 -g -h "NSS Generic Crypto Services" -k 2048


Generating RSA key.  This may take a few moments...

Using PKCS#11 with temporary 2048 bits key in token NSS Generic Crypto
Services.
1206 iterations in 5 seconds
241.18 operations/s .
one operation every 4146 microseconds
[jp96085@nss-amd-solaris]/h/monstre/export/home/tip/mozilla/dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/bin
116 % ./rsaperf -d . -s -p 5 -g -h "NSS Generic Crypto Services" -k 4096


Generating RSA key.  This may take a few moments...

Using PKCS#11 with temporary 4096 bits key in token NSS Generic Crypto
Services.
204 iterations in 5.002 seconds
40.78 operations/s .
one operation every 24520 microseconds
[jp96085@nss-amd-solaris]/h/monstre/export/home/tip/mozilla/dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/bin
117 % ./rsaperf -d . -s -p 5 -g -h "NSS Generic Crypto Services" -k 8192


Generating RSA key.  This may take a few moments...

Using PKCS#11 with temporary 8192 bits key in token NSS Generic Crypto
Services.
30 iterations in 5.073 seconds
5.91 operations/s .
one operation every 169 milliseconds

Here is another result with a 1024 bit token private key :

[jp96085@nss-amd-solaris]/h/monstre/export/home/tip/mozilla/dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/bin
119 % ./rsaperf -d . -s -p 5 -n monstre.red.iplanet.com
Enter Password or Pin for "NSS Certificate DB":
Using PKCS#11 for RSA decryption with token NSS Certificate DB.
5250 iterations in 5 seconds
1049.85 operations/s .
one operation every 952 microseconds

And our hardcoded 1024 bit key direct to freebl :

[jp96085@nss-amd-solaris]/h/monstre/export/home/tip/mozilla/dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/bin
122 % ./rsaperf -d . -s -p 5
5722 iterations in 5 seconds
1144.29 operations/s .
one operation every 873 microseconds
[jp96085@nss-amd-solaris]/h/monstre/export/home/tip/mozilla/dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/bin
123

In summary, for 1024 bit keys, the PKCS#11 token object key runs at 1049 ops/s,
the PKCS#11 session object key runs at 1156 ops, and the freebl key at 1147
ops/s. The last two numbers should be reversed ! Perhaps the difference is due
to the different key. I still need to fix the hardcoded key import to make it
100% apples to apples.

What's important to note here is that the token private key runs 10% slower in
this case than with freebl. Fixing bug 274538 will probably resolve the
disparity.

Comment 5

[Julien Pierre]

Attachment: add PKCS#11 support to rsaperf

This patch adds a number of options to rsaperf :

-h token to select a slot for RSA session keygen and perf testing

-x exponent to select the exponent for RSA keygen (in case this was ever
relevant for performance)

-g to force a keygen . If the key size is 1024 bits and freebl is selected, by
default, a RSA hardcoded key is used

-n token:nickname to select a cert and use its private or public key .
This option is not new, but it was not implemented before, all code was
ifdef'ed out . It is now implemented, and will use a token private key. For the
public key, it gets imported to the certs' PKCS#11 slot. I didn't want the
selected slot to be left to the hazards of secmod.db for this benchmark .

-k size to select the RSA keylength . For PKCS#11 session objects or freebl
only .

-

Comment 6

[Julien Pierre]

FYI, the results reported in comment #4 were incorrect because of a statistical
error : the 5 seconds interval was just too short.

When running with a longer interval, doing RSA direct in freebl turns out to be
about 1-2% faster than using RSA with session keys.

Doing RSA with session keys remains up to 10% faster than with token keys, which
is expected due to the DES unwrap.

Since there is no longer an anomaly to explain, I felt there was no need to
write the additional code to import our hardcoded key to the softoken. We have
gone out of our way in NSS to make it hard to use raw keys, and it seemed like a
lot of work. It doesn't seem that the performance our current RSA algorithm
depends on the key value, so this work is probably not needed.

For the same reasons, I saw no needed to add other hardcoded keys beyond the one
1024 bit key that's in defkey.c at this time.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 178902 [details] [diff] [review]
add PKCS#11 support to rsaperf

I denied this patch because it changes the valid combination of command line
options in a way that I believe would cause existing test scripts to break. 
Specifically, it changes the program to always require the -d option, even when
using NoDBInit. 
I also suggested a number of other changes in email.

Comment 8

[Julien Pierre]

Attachment: patch udpate

Merge with the tip and update from Nelson's review feedback.

Comment 9

[Julien Pierre]

Nelson, please ignore the following line in your review, as it is in error :

+        (useTokenKey && publicExponent) ||

Comment 10

[Julien Pierre]

Attachment: one more update

During testing, problems were found with the threading code changes from bug
287625 . The time computation attempted to compensate for thread startup time,
but it was incorrect and caused bogus results with large number of threads. I
have fixed this problem in this new patch.

I also added calls to SECKEY_CacheStaticFlags to reduce the calls to
C_GetAttributeValue when using PKCS#11 keys (both session or token).

Comment 11

[Julien Pierre]

Attachment: fix session key case with 3rd party tokens

I'm afraid another bug was still present. For the session keys case, rsaperf
was using NSS_NoDB_Init . This still allowed testing session keys with NSS
softoken, but not with any other token. The present patch - and hopefully last
one for this bug - fixes this problem.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 179136 [details] [diff] [review]
one more update

I'm marking this patch obsolete because it appears that julien intended for
this patch to be superseded by the patch that follows it.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 179140 [details] [diff] [review]
fix session key case with 3rd party tokens

There's always room for more improvement, but this patch does what it intended.

Comment 14

[Julien Pierre]

Thanks, Nelson !

I checked this in to the tip for 3.10 .

Checking in rsaperf.c;
/cvsroot/mozilla/security/nss/cmd/rsaperf/rsaperf.c,v  <--  rsaperf.c