OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [pkcs11] CKA_PUBLIC_KEY_INFO


On 4/12/2013 1:23 AM, Peter Gutmann wrote:
There's really no need for this since the implementation can pretty trivially
generate the CKA_PUBLIC_KEY_INFO from information it already has CKA_VALUE for
DSA, CKA_MODULUS etc for RSA, and so on.

Actually - no.

Both the public and private keys for RSA are derived from two randomly generated primes p and q. There are three common models for storing private key info - { n, d } modulus and private exponent, { n, d, p, q } modulus, private exponent, generator primes, and finally the Chinese Remainder Theorem form (which also contains the generator primes). As far as I can tell from perusing the math, you can't get from a { n, d} private key to the public key as you need p-1 and q-1 to generate it. [Not a crypto mathematician, but the math seems simple enough to follow].

So I added this to the C_CreateObject stuff to support pushing a key pair where you only have the { n, d } values. The FIPS guidance requires verifying correspondence between public and private keys and I think it makes sense to enforce this here.

EC doesn't have this problem as the public key is { k * G } where k is the private key and G is the generator point on the curve.

I haven't looked at DH, DSA or KEA as of yet. (Or GOST for that matter).

Mike





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]