[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-cryptoapi
Subject:    Re: How to handle multiple keypairs?
From:       Jeff Spelman <jeffspel () MICROSOFT ! COM>
Date:       1997-02-28 21:35:20
[Download RAW message or body]


Bob
   You should be able to use CryptoAPI to do what you describe.  You are
correct that you can only import one private key at a time, subsequent
calls to CryptImportKey will overwrite previous private keys.  With the
MS Providers there aren't restrictions on the number of key containers
you can create, however other CSPs, hardware for example may have such
restrictions.

   There are some multithreading bugs with the MS Providers, so I cannot
guarantee that what you want to do will be thread safe.

Thanks, Jeff

>----------
>From:  Bob Denny[SMTP:rdenny@DC3.COM]
>Sent:  Friday, February 28, 1997 11:21 AM
>To:    CryptoAPI@LISTSERV.MSN.COM
>Subject:       How to handle multiple keypairs?
>
>I have an application that needs to use RSA encryption communicate on behalf
>of a number of identities, several hundred or more (no RSA is not being used
>for bulk encryption! This is for key exchange and authentication). In order
>to
>do this, the application needs access to a cert and PRIVATE key for each of
>these identities.
>
>My problem is with the private keys. They need to be persistently stored in
>standard PKCS #8 format (safely encrypted of course). At startup, I read
>these
>keys, decrypt them, and convert to MS-proprietary PRIVATEKEYBLOB format and
>used with a HCRYPTKEY handle. I have worked out the conversion from PKCS #8
>to
>PRIVATEKEYBLOB (at least CryptImportKey() succeeds! Once.). However, it
>appears that I cannot import "many" of these keys and just use them via the
>HCRYPTKEY handle.
>
>Is this right?
>
>Am I limited to 1 each "key exchange" and "signature" keypair per key
>container?
>
>If so, it is reasonable to call CryptAcquireContext() hundreds of times,
>specifying a different named key container each time?
>
>If so, can I then CryptImportKey() each of the keys into its own container,
>and then successfully use the HCRYPTKEY handles?
>
>Is this thread-safe?
>
>Am I out in left field? :-)
>
>I'd normally just implement something and try it, but this is a hell of a lot
>of work, and it seems outside the envelope for CryptoAPI. Therefore, I'd like
>to have a "second opinion" before jamming a pile of time into what may be a
>dead end.
>
>  -- Bob
>

[prev in list] [next in list] [prev in thread] [next in thread]