On 18 mar, 17:20, Robert Relyea <rrel...@redhat.com> wrote: > On 03/18/2011 08:06 AM, Superpacko wrote: > > > > > > > > > > > On 17 mar, 18:35, Robert Relyea <rrel...@redhat.com> wrote: > >> On 03/17/2011 11:33 AM, Superpacko wrote: > > >>> On 17 mar, 15:20, Robert Relyea <rrel...@redhat.com> wrote: > >>>> On 03/16/2011 01:54 PM, Superpacko wrote:> Hi, im working on a software > >>>> that uses GPG as a Key Manager but leaves > >>>>> the encryption operations to NSS. I'm having a hard time trying to > >>>>> figure out how to import GPG's public and private keys in NSS. > >>>>> GPG stores the keys in "PKT_public_key" and "PKT_private_key" > >>>>> structures, both have a "MPI pkey[PUBKEY_MAX_NPKEY];" which is what i > >>>>> need to import in NSS if im not wrong. > >>>> What does the full struct look like, and what is the length of > >>>> PUBKEY_MAX_NPKEY. > >>> #define PUBKEY_MAX_NPKEY 4 > >>> MPI pkey[PUBKEY_MAX_NPKEY]; > >>> } PKT_public_key; > >>> This is the struct. GPG stores the data in the MPI structures that are > >>> used in Lybcrypt. > >> did you really mean 'lybcrypt' or did you mean 'libcrypt' or > >> 'libgcrypt'? What you need is documentation for how the key is really > >> stored in this object.> I found out that NSS has these functions: > > >>> SECKEYPublicKey* SECKEY_ImportDERPublicKey(SECItem *derKey, > >>> CK_KEY_TYPE type); //with CKK_RSA > >>> SECStatus PK11_ImportDERPrivateKeyInfo(PK11SlotInfo *slot, SECItem > >>> *derPKI, SECItem *nickname, SECItem *publicValue, PRBool isPerm, > >>> PRBool isPrivate, unsigned int usage, void *wincx); > >>> SECStatus PK11_ImportDERPrivateKeyInfoAndReturnKey(PK11SlotInfo *slot, > >>> SECItem *derPKI, SECItem *nickname, SECItem *publicValue, PRBool > >>> isPerm, PRBool isPrivate, > >>> unsigned int usage, SECKEYPrivateKey** privk, void *wincx); > >> These functions are taking DER encoded data. DER encoded data are not > >> strings. You will need a pointer and a length. I would be surprised if > >> the data in MPI is DER encoded without anything else. Getting DER from > >> the MPI structure is probably your best bet if you can find the > >> appropriate call in your crypto library. > > >>> Im assuming that i can pass this MPIs data as char* and store it in a > >>> SECItem like: > >>> SECItem derKey; > >>> derKey.type = siBuffer; > >>> derKey.data = (unsigned char*)key; > >>> and then pass it to the import function. What do u think about this? > >> You are missing derKey.len > > >> bob > > First of all, thank you for replying so fast. Im pretty lost with this > > thing. > > > I meant Libgcrypt, and so far im not able to find a way to get DER > > keys from the MPI values. > > GPG uses libgcrypt for the encryption, so passing MPI keys to > > libgcrypt solves the problem for them. > > Since i have to use NSS, the only functions to import public and > > private keys that i found are the ones taking DER keys. > > > Is there any other way to import keys into NSS? Im stuck with the MPI > > data, so somehow im gonna have to import that in NSS. > > There are several, but it requires you to somehow get the key in some > sort of standard format. There's not much we can do if GPG and > libgcrypt only support their own effectively proprietary* key format... > > Can you get the keys in pem, pkcs#11, or even just actual component format? > > bob > > *if seems unlikely that a gnu project wouldn't support any open standards...
i see.. i've been doing some research today, so far i found that libgcrypt can convert an internal MPI representation to this formats: GCRYMPI_FMT_STD 2-complement stored without a length header. GCRYMPI_FMT_PGP As used by OpenPGP (only defined as unsigned). This is basically GCRYMPI_FMT_STD with a 2 byte big endian length header. GCRYMPI_FMT_SSH As used in the Secure Shell protocol. This is GCRYMPI_FMT_STD with a 4 byte big endian header. GCRYMPI_FMT_HEX Stored as a C style string with each byte of the MPI encoded as 2 hex digits. When using this format, buflen must be zero. GCRYMPI_FMT_USG Simple unsigned integer. thats what i was able to get today, does this help? tomorrow i may get a suggestions from another colleague, so i'll share that as well. thanks so much! -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
