Garrett D'Amore wrote: > Just a quick note: I don't know how many generations you need to remove > the statistical anamolies, but unless you "try" the same random numbers > as starting points, you might get quite different performance results on > two separate key generations. The problem is that if you get lucky, you > will get a prime number within the first couple of tries. But you could > get quite unlucky and have to run a lot more tests. (Perhaps you could > record the number of failed tries and divide the total run time by > number of failed tries? That would provide some leveling to ensure a > fair comparision.) > > Possibly 100 key pairs is enough to remove statistical variance. But > I'm not sure. > Generating 1000 key pairs was very close to 10 times the time for 100 pairs. I haven't tried different key sizes, but either way you cook it, hardware acceleration is definitely faster.
> There's some general rule about the distribution of prime numbers, but I > don't remember what it is. > > -- Garrett > > Mark Powers wrote: > >> Garrett, >> >> Yes the "is prime" test is hardware accelerated. >> A micro benchmark test that generated 100 RSA key pairs >> ran 10 times faster than when run in softtoken. >> I was generating keys with 1024 bit modulus. >> >> Of course applications may not always get these >> numbers but their RSA key generation should be faster. >> >> >> Mark >> >> Garrett D'Amore wrote: >> >>> It can significantly accelerate key generation? Wow, that sounds >>> interesting. Is this something more than just providing good random >>> data? Does it accelerate the "is prime" test in hardware? >>> >>> -- Garrett >>> >>> Darren J Moffat wrote: >>> >>> >>>> Subject: PSARC FastTrack [02/13/2007]: key generation and derivation >>>> for providers without keystore >>>> >>>> I'm submitting this case as closed approved automatic. It only >>>> modifies >>>> Consolidation Private or Project Private interfaces and does so in a >>>> compatible way. >>>> >>>> Template Version: @(#)sac_nextcase %I% %G% SMI >>>> 1. Introduction >>>> 1.1 Project/Component Working Name: >>>> key generation and derivation for providers without keystore >>>> 1.2 Name of Document Author/Supplier: >>>> Mark Powers, Anthony Scarpino >>>> 1.3 Date of this Document: >>>> 2/12/2007 >>>> >>>> 4. Technical Description >>>> >>>> The Interface taxonomy is Consolidation Private. >>>> The Release taxonomy is Patch/Micro >>>> >>>> Diff-marked draft manpages, cspi design, and header files are >>>> included >>>> in the case directory. >>>> >>>> 4.0 Background >>>> >>>> The ncp provider, which is available on sun4v machines, is capable >>>> of significantly accelerating RSA and Diffie-Hellman (DH) key >>>> generation >>>> and derivation. However, it is not possible to take advantage of >>>> this >>>> because the existing Service Provider Interface (SPI) assumes >>>> providers >>>> capable of generating and deriving keys also have a keystore, and >>>> that >>>> keys are returned by reference rather than value. This proposal >>>> seeks >>>> to remove this limitation. >>>> >>>> 4.1 Proposal >>>> >>>> The case proposes the following: >>>> >>>> - modifications to the kcf kernel module to support new provider >>>> entry points for the generation and derivation of keys. The >>>> new >>>> entry points have two arguments per key instead of one. The >>>> extra >>>> argument is reserved for attributes that need to be copied >>>> back >>>> into a user's address space. Providers that register the new >>>> entry points should not register key ops (crypto_key_ops(9S)) >>>> which are reserved for providers with keystores. Providers >>>> with >>>> these new entry points register SPI version 3. >>>> >>>> - modifications to pkcs11_kernel - a user library component - >>>> to use >>>> the new key generation and derivation entry points. The >>>> gist of >>>> this modification is to add additional PKCS#11 RSA and DH >>>> attributes >>>> to key templates so that generated and derived keys can be >>>> returned >>>> by value rather than by reference. Generated and derived >>>> keys will >>>> be stored as session objects by pkcs11_kernel.so. >>>> >>>> - modifications to metaslot and softtoken to move session keys >>>> from pkcs11_kernel to pkcs11_softtoken where they can be >>>> stored >>>> as token keys. Token keys are persistent objects whereas >>>> session >>>> keys are destroyed when sessions are closed. >>>> >>>> - modifications to the ncp driver to use version 3 of the SPI. >>>> The driver will be modified to support >>>> CKM_RSA_PKCS_KEY_PAIR_GEN, >>>> CKM_DH_PKCS_KEY_PAIR_GEN, and CKM_DH_PKCS_DERIVE. >>>> >>>> The new SPI entry points (see spi.h) are: >>>> int (*nostore_key_generate)(crypto_provider_handle_t, >>>> crypto_session_id_t, crypto_mechanism_t *, >>>> crypto_object_attribute_t *, uint_t, >>>> crypto_object_attribute_t *, >>>> uint_t, crypto_req_handle_t); >>>> >>>> int (*nostore_key_generate_pair)(crypto_provider_handle_t, >>>> crypto_session_id_t, crypto_mechanism_t *, >>>> crypto_object_attribute_t *, uint_t, >>>> crypto_object_attribute_t *, >>>> uint_t, crypto_object_attribute_t *, uint_t, >>>> crypto_object_attribute_t *, uint_t, crypto_req_handle_t); >>>> >>>> int (*nostore_key_derive)(crypto_provider_handle_t, >>>> crypto_session_id_t, >>>> crypto_mechanism_t *, crypto_key_t *, >>>> crypto_object_attribute_t *, >>>> uint_t, crypto_object_attribute_t *, uint_t, >>>> crypto_req_handle_t); >>>> >>>> 4.1.1 Compatibility >>>> >>>> The SPI interface was introduced by PSARC 2001/553. PSARC >>>> 2005/576 >>>> changed the interface version from 1 to 2. The kernel kcf >>>> module will >>>> remain backwards compatible with version 1 and 2 providers. >>>> >>>> 4.2 Bug/RFE Number(s): 6339802, 6462782, 6462780 >>>> >>>> 4.5 Exported Interfaces: >>>> >>>> +--------------------------------+---------------------------+--------------+ >>>> >>>> | Interface | Classification | >>>> Comments | >>>> +--------------------------------+---------------------------+--------------+ >>>> >>>> | impl.h | Consolidation | >>>> include file | >>>> | | Private >>>> | | >>>> | | >>>> | | >>>> | ioctl.h | Project Private | >>>> include file | >>>> | | >>>> | | >>>> | ops_impl.h | Consolidation | >>>> include file | >>>> | | Private >>>> | | >>>> | | >>>> | | >>>> | spi.h | Consolidation | >>>> include file | >>>> | | Private >>>> | | >>>> | | >>>> | | >>>> | ncp.h | Consolidation | >>>> include file | >>>> | | Private >>>> | | >>>> +--------------------------------+---------------------------+--------------+ >>>> >>>> >>>> 6. Resources and Schedule >>>> 6.4. Steering Committee requested information >>>> 6.4.1. Consolidation C-team Name: >>>> ON >>>> 6.5. ARC review type: FastTrack >>>> _______________________________________________ >>>> crypto-discuss mailing list >>>> crypto-discuss at opensolaris.org >>>> http://opensolaris.org/mailman/listinfo/crypto-discuss >>>> >>>> >>> >>> > > >
