From sacadmin Tue Feb 13 13:56:12 2007 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.45]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1DLuC9d010599; Tue, 13 Feb 2007 13:56:12 -0800 (PST) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l1DLuB3J342395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Feb 2007 13:56:11 -0800 (PST) Received: (from darrenm@localhost) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8/Submit) id l1DLuBNR342391; Tue, 13 Feb 2007 13:56:11 -0800 (PST) Date: Tue, 13 Feb 2007 13:56:11 -0800 (PST) From: Darren J Moffat Message-Id: <200702132156.l1DLuBNR342391@jurassic.eng.sun.com> To: PSARC@sac.sfbay.sun.com Cc: crypto-discuss@opensolaris.org Subject: key generation and derivation for providers without keystore [PSARC/2007/092 Timeout: 02/13/2007] Status: RO Content-Length: 5453 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 From sacadmin Tue Feb 13 14:41:32 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1DMfWT5012073 for ; Tue, 13 Feb 2007 14:41:32 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l1DMfW7U016034 for ; Tue, 13 Feb 2007 14:41:32 -0800 (PST) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1DMdRRi024884 for ; Tue, 13 Feb 2007 14:41:32 -0800 (PST) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay43i.sun.com with ESMTP; Tue, 13 Feb 2007 22:41:32 Z Received: from relay44i.sun.com ([192.5.209.118] [192.5.209.118]) by mms49es.sun.com with ESMTP; Tue, 13 Feb 2007 22:41:31 Z Received: from mail.tadpolecomputer.co.uk ([82.111.17.14] [82.111.17.14]) by relay4i.sun.com with ESMTP; Tue, 13 Feb 2007 22:41:31 Z Received: from zippy.garrett ([192.168.251.21]) by mail.tadpolecomputer.co.uk with esmtp (Exim 4.66) (envelope-from ) id 1HH6L4-0004G6-H4; Tue, 13 Feb 2007 22:41:30 +0000 Message-Id: <45D23E97.6060800@tadpole.com> Date: Tue, 13 Feb 2007 14:41:27 -0800 From: "Garrett D'Amore" User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: Darren J Moffat CC: PSARC@sac.sfbay.sun.com, crypto-discuss@opensolaris.org Subject: Re: [crypto-discuss] key generation and derivation for providers without keystore [PSARC/2007/092 Timeout: 02/13/2007] References: <200702132156.l1DLuBNR342391@jurassic.eng.sun.com> In-Reply-To: <200702132156.l1DLuBNR342391@jurassic.eng.sun.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 6265 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@opensolaris.org > http://opensolaris.org/mailman/listinfo/crypto-discuss > -- Garrett D'Amore, Principal Software Engineer Tadpole Computer / Computing Technologies Division, General Dynamics C4 Systems http://www.tadpolecomputer.com/ Phone: 951 325-2134 Fax: 951 325-2191 From sacadmin Tue Feb 13 16:10:50 2007 Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1E0AncX013507 for ; Tue, 13 Feb 2007 16:10:50 -0800 (PST) Received: from [192.9.61.140] (punchin-client-192-9-61-140.SFBay.Sun.COM [192.9.61.140]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l1E0AmP26158; Tue, 13 Feb 2007 16:10:48 -0800 (PST) Message-ID: <45D25387.9030909@sun.com> Date: Tue, 13 Feb 2007 17:10:47 -0700 From: Mark Powers User-Agent: Thunderbird 1.5.0.8 (X11/20061204) MIME-Version: 1.0 To: "Garrett D'Amore" CC: Darren J Moffat , PSARC@sac.sfbay.sun.com, crypto-discuss@opensolaris.org Subject: Re: [crypto-discuss] key generation and derivation for providers without keystore [PSARC/2007/092 Timeout: 02/13/2007] References: <200702132156.l1DLuBNR342391@jurassic.eng.sun.com> <45D23E97.6060800@tadpole.com> In-Reply-To: <45D23E97.6060800@tadpole.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 6556 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@opensolaris.org >> http://opensolaris.org/mailman/listinfo/crypto-discuss >> >> > > > From sacadmin Tue Feb 13 16:16:23 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1E0GNsG013544 for ; Tue, 13 Feb 2007 16:16:23 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l1E0GNkB028265 for ; Tue, 13 Feb 2007 16:16:23 -0800 (PST) Received: from relay3.sun.com (relay3.sun.com [150.143.103.54] (may be forged)) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1DMQNfd018178 for ; Tue, 13 Feb 2007 17:16:23 -0700 (MST) Received: from mms0ees.sun.com ([150.143.104.244] [150.143.104.244]) by relay3.sun.com with ESMTP; Wed, 14 Feb 2007 00:16:10 Z Received: from relay4.sun.com (relay4.sun.com [150.143.103.74]) by mms0ees.sun.com with ESMTP; Wed, 14 Feb 2007 00:16:10 Z Received: from mail.tadpolecomputer.co.uk ([82.111.17.14] [82.111.17.14]) by relay4.sun.com with ESMTP; Wed, 14 Feb 2007 00:16:09 Z Received: from zippy.garrett ([192.168.251.21]) by mail.tadpolecomputer.co.uk with esmtp (Exim 4.66) (envelope-from ) id 1HH7oe-0005ZE-F5; Wed, 14 Feb 2007 00:16:08 +0000 Message-Id: <45D254C6.2040900@tadpole.com> Date: Tue, 13 Feb 2007 16:16:06 -0800 From: "Garrett D'Amore" User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: Mark Powers CC: Darren J Moffat , PSARC@sac.sfbay.sun.com, crypto-discuss@opensolaris.org Subject: Re: [crypto-discuss] key generation and derivation for providers without keystore [PSARC/2007/092 Timeout: 02/13/2007] References: <200702132156.l1DLuBNR342391@jurassic.eng.sun.com> <45D23E97.6060800@tadpole.com> <45D25387.9030909@sun.com> In-Reply-To: <45D25387.9030909@sun.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 7901 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. 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@opensolaris.org >>> http://opensolaris.org/mailman/listinfo/crypto-discuss >>> >> >> >> -- Garrett D'Amore, Principal Software Engineer Tadpole Computer / Computing Technologies Division, General Dynamics C4 Systems http://www.tadpolecomputer.com/ Phone: 951 325-2134 Fax: 951 325-2191 From sacadmin Tue Feb 13 17:27:06 2007 Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1E1R5Zl014713 for ; Tue, 13 Feb 2007 17:27:06 -0800 (PST) Received: from [192.9.61.140] (punchin-client-192-9-61-140.SFBay.Sun.COM [192.9.61.140]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l1E1R4P27037; Tue, 13 Feb 2007 17:27:04 -0800 (PST) Message-ID: <45D26567.9040407@sun.com> Date: Tue, 13 Feb 2007 18:27:03 -0700 From: Mark Powers User-Agent: Thunderbird 1.5.0.8 (X11/20061204) MIME-Version: 1.0 To: "Garrett D'Amore" CC: PSARC@sac.sfbay.sun.com, Darren J Moffat , crypto-discuss@opensolaris.org Subject: Re: [crypto-discuss] key generation and derivation for providers without keystore [PSARC/2007/092 Timeout: 02/13/2007] References: <200702132156.l1DLuBNR342391@jurassic.eng.sun.com> <45D23E97.6060800@tadpole.com> <45D25387.9030909@sun.com> <45D254C6.2040900@tadpole.com> In-Reply-To: <45D254C6.2040900@tadpole.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 8181 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@opensolaris.org >>>> http://opensolaris.org/mailman/listinfo/crypto-discuss >>>> >>>> >>> >>> > > > From sacadmin Wed Feb 14 13:06:04 2007 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1EL64HN009060 for ; Wed, 14 Feb 2007 13:06:04 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l1EL5xIC003803; Wed, 14 Feb 2007 16:05:59 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l1EL5whR025384; Wed, 14 Feb 2007 16:05:58 -0500 (EST) Subject: Re: key generation and derivation for providers without keystore [PSARC/2007/092 Timeout: 02/13/2007] From: Bill Sommerfeld To: Darren J Moffat Cc: PSARC@sac.sfbay.sun.com, crypto-discuss@opensolaris.org In-Reply-To: <200702132156.l1DLuBNR342391@jurassic.eng.sun.com> References: <200702132156.l1DLuBNR342391@jurassic.eng.sun.com> Content-Type: text/plain Date: Wed, 14 Feb 2007 16:05:57 -0500 Message-Id: <1171487157.23037.22.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 365 On Tue, 2007-02-13 at 13:56 -0800, 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. The case was actually filed "closed approved fast-track" which was a process error; I've corrected it to the appropriate state. - Bill From sacadmin Wed Feb 14 13:21:41 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1ELLfN5009473 for ; Wed, 14 Feb 2007 13:21:41 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l1ELLeEU012842 for ; Wed, 14 Feb 2007 13:21:41 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1ELLYfh007509 for ; Wed, 14 Feb 2007 21:21:35 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JDH009011Z26D00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC@sac.sfbay.sun.com; Wed, 14 Feb 2007 21:21:34 +0000 (GMT) Received: from [10.192.15.79] (192-18-45-134.Sun.COM [192.18.45.134]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JDH00AEJ1ZWOB40@d1-emea-09.sun.com>; Wed, 14 Feb 2007 21:21:34 +0000 (GMT) Date: Wed, 14 Feb 2007 21:21:32 +0000 From: Darren J Moffat Subject: Re: key generation and derivation for providers without keystore [PSARC/2007/092 Timeout: 02/13/2007] In-reply-to: <1171487157.23037.22.camel@thunk> Sender: Darren.Moffat@Sun.COM To: Bill Sommerfeld Cc: Darren J Moffat , PSARC@sac.sfbay.sun.com, crypto-discuss@opensolaris.org Message-id: <45D37D5C.7080304@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200702132156.l1DLuBNR342391@jurassic.eng.sun.com> <1171487157.23037.22.camel@thunk> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 564 Bill Sommerfeld wrote: > On Tue, 2007-02-13 at 13:56 -0800, 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. > > The case was actually filed "closed approved fast-track" which was a > process error; I've corrected it to the appropriate state. Thanks, It would help if sac_nextcase actually had the concept of closed approved automatic instead of us having to hand craft it. Similarly for open cases. -- Darren J Moffat