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@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
