On 05/01/2012 12:01 PM, VJ wrote:
> On Tuesday, 1 May 2012 00:46:21 UTC+8, Robert Relyea wrote:
>> On 04/30/2012 02:22 AM, VJ wrote:
>>> Hi,
>>> I've tested encryption, decryption, signing and verification with public (NSSLOWKEYPublicKey) and private keys (NSSLOWKEYPrivateKey) in low level.
>> Big question, Why are you using private interfaces? The low level
>> interfaces are only for specific operations, and not for applications
>> for most libraries. What is it you are trying to do?
>>
>> bob
>>> However, Now I have a public/private keys in the below format:
>>>
>>> -----BEGIN RSA PUBLIC KEY-----
>>> MIGHAoGBAK12Da7PWjz1Yf01Hp2gaRxBWU2lXchh/lGaQI05JusLgI38DSN2ZPW5
>>> x6Ff6ZOztEb9sc6oz7NdrZy68Veb+tcD/3A6qZRUUDAW0aFOJZIcl0U+IZXvguqa
>>> TxSRDTvBwqCp44PaWYiwtdP5vnjfPXFgHLLMvM7yzOedRttDNpYDAgED
>>> -----END RSA PUBLIC KEY-----
>>>
>>>
>>> -----BEGIN RSA PRIVATE KEY-----
>>> MIICWwIBAAKBgQCtdg2uz1o89WH9NR6doGkcQVlNpV3IYf5RmkCNOSbrC4CN/A0j
>>> dmT1ucehX+mTs7RG/bHOqM+zXa2cuvFXm/rXA/9wOqmUVFAwFtGhTiWSHJdFPiGV
>>> 74Lqmk8UkQ07wcKgqeOD2lmIsLXT+b543z1xYByyzLzO8sznnUbbQzaWAwIBAwKB
>>> gHOkCR805tNOQVN4vxPARhLWO4kY6TBBVDZm1bN7b0ddAF6oCMJO7fkmhRY/8Q0i
>>> eC9Ty98bNSI+c73R9jpn/I4+dSXO3HvILYfmIsnrVnbDwQgKlr2+/LBHXYFW91XK
>>> 5DJzb3nI2yEF4Khxk5UiQEppI4QcYu4ndOPRoyq4cFUbAkEA4JjkWdHG4KaixLXW
>>> TTkgo1GdvNcbseCi4R2IqjlzIhoLFxMwLFEB30BwkCzLEDhxW8Pr2dErkL57OWaJ
>>> hkmcTwJBAMW20yqNE8dlQXjnnB/qv1OkG3FoXZ8nP04lSeRgx+9SSeWpHQC/1Uik
>>> Zr80ThukkGajgMhXPibfFqlrkahEeg0CQQCVu0Lmi9nrGcHYeTmI0MBs4RPTOhJ2
>>> lcHraQXG0PdsEVy6DMrINgE/gEsKyIdgJaDn1/KRNh0LKad7mbEEMRLfAkEAg883
>>> cbNihO4rpe+9apx/jRgSS5rpFMTU3sOGmECFSjbb7nC+AH/jhcLvKiLevRhgRG0A
>>> hY9+xJS5xke2cC2mswJAFDGCpvh9ChK1VAXjmDxDI6CZA0ekekTxqxmMe2dt2FyL
>>> Rlb+yM60zguFxqR3h2O5uYa+NcntYztMjEeQP/386w==
>>> -----END RSA PRIVATE KEY-----
>>>
>>>
>>> My question is, Is there a way that I can make these suitable for NSSLOWKEYPublicKey and NSSLOWKEYPrivateKey structures?
>>>
>>> Thanks,
>>> Vejey
> Hi Bob,
>
> I'm extracting private interfaces for RSA functions compatible for our own VM, with our own instruction sets. Even, Dynamic memory allocation cannot work there.
> I've tested these low level functionality for RSA.
This seems surprising with out modifying mpi. The underlying mpi code
assumes that it can allocate data, so unless you are faking it out with
some sort of manual allocator, I don't see how you can even get a basic
RSA op to work.
>
> Now, Is there a way to get the above keys - stripped and make it work in low level?
> Is it feasible? or I should consider doing something else?
If you are trying to decode this in an enviroment that can't allocate
data, you are in for some difficulty. To decode the above you need: 1) a
base64 decoder, and 2) an asn1/der decoder. There are some internal NSS
templates to do this (as least the der part). Of course if you can't
allocate, non of the NSS decoders would work for you (The simplest
requires NSPR arenas).
Anyway the path forward is to do a base64 decode on the above data (you
have to strip the ---- XXXXX----- portions yourself. The function you
want is ATOB, so either ATOB_convertAsciiToItem or ATOB_AsciiToData()
(defined in base64.h).
Once you have the binary you want to decode the DER value. You can see
some samples in mozilla/security/nss/lib/softoken/legacydb/keydb.c. The
function seckey_decrypt_private_key is mostly what you want. You just
need to skip the actual decrypt step. The public key function would be
similiar, except you use a different template (and the key has fewer
components).
If you were operating from the proper NSS layer you could use
PK11_ImportDERPrivateKeyInfoAndReturnKey() for the private key and
SECKEY_DecodeDERPublicKey() for the public key (both still require ATOB_
first).
bob
>
> Thanks,
> Vejey
--
dev-tech-crypto mailing list
dev-tech-crypto@...
https://lists.mozilla.org/listinfo/dev-tech-crypto