NZzi wrote:
Robert Relyea wrote:
NZzi wrote:
hi all:
I want to use private key to encrypt a message,
and decrypt with public key.
Are you encrypting data or a symmetric Key?
Most of the nss code that does these operations does so on actual
symetric keys (which are then used to do additional
encryption/decryption/macing).
In that case they are using the PK11_PubWrapSymKey() and
PK11_PubUnwrapSymKey().
bob
i find PK11_PubEncryptPKCS1() in mailing list
discussion, which seems to do the padding. But
i want to use private key to encrypt, not
public key. And what's more, there are not any
doc or example codes to show PK11_PubEncryptPKCS1()
usage
OK, so here's a question, what is it you are trying to do? Encrypting
with the private key is really called 'Signing'. The equivalent
function is PK11_Sign. If you are doing key distribution, or you are
trying to pass secret data to someone else you want to encrypt with
the public key, so only the person with the private key can decrypt
it. Encrypting with the private key, in this case, will allow anyone
to read the result by 'decrypting' with the public key.
In the sign case, you don't care about secrecy, you want to 'prove'
you hold the private key. In that case you 'encrypt' data with that
private key. I know you have the private key because I get the correct
data back when I 'decrypt' with the public key. This recovery process
is a verification, so it's called PK11_Verify, except you are looking
for the actual data to recover, not to verify that the data matches.
This operation is *VERY* RSA specific. No other signing/verification
method uses it. In that case you need to call the special function
PK11_VerifyRecover. These names match their PKCS #11 equivalents in
the PKCS #11 spec.
An important note about this. NSS allows this. There are cases where
you do need to use PK11_VerifyRecover rather than PK11_Verify, or more
specificially, the high level SGN_ and VFY_ functions. HOWEVER, there
should be warning signs in your head if you have to resort to these
cases. First, you will likely be generating signatures that no one
else will be able to validate (All toolkits know how to deal with an
RSA signature with PKCS #1 padding *AND* properly ASN1 wrapped digests
- even better wrapped as an ASN1 signing wrapper). Second, you are
tying your application strongly to RSA. The world of crypto is
littered with the dead bodies of once strong algorithms which have
fallen to the increasingly sophisticated attacks of the cryptanalyst.
RSA is still strong today (albeit weaker than when I first started
working in crypto), but that may not stay forever. Tying yourself to a
specific algorithm is not a good idea.
All that being said the mapping of high level/crypto operation names
to low level RSA operations is as follows:
Encrypt with public Key (PKCS #1 padding): PK11_PubEncryptPKCS1()
Decrypt with private Key (PKCS #1 padding): PK11_PrivDecryptPKCS1()
Encrypt with private Key (PKCS #1 padding): PK11_Sign() (use mechanism
CKM_RSA_PKCS1)
Decrypt with public Key (PKCS #1 padding): PK11_VerifyRecover() (use
mechanism CKM_RSA_PKCS1)
I'm sorry for my nonsense words, i'm mad about using nss in my code
last night.
I just want to use private key to encrypt a message(>key modulus len),
and recover/decrypt the message using public key, without caring
about anything about padding PKCS#1/PKCS#11. I only know little
about cryptography.
following is my test code:
#define BASE64_ENCODED_SUBJECTPUBLICKEYINFO
"MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAL3F6TIc3JEYsugo+a2fPU3W+Epv/FeIX21DC86WYnpFtW4srFtz2oNUzyLUzDHZdb+k//8dcT3IAOzUUi3R2eMCAwEAAQ=="
#define BASE64_ENCODED_PRIVATEKEYINFO
"MIIBVQIBADANBgkqhkiG9w0BAQEFAASCAT8wggE7AgEAAkEAvcXpMhzckRiy6Cj5rZ89Tdb4Sm/8V4hfbUMLzpZiekW1biysW3Pag1TPItTMMdl1v6T//x1xPcgA7NRSLdHZ4wIDAQABAkEAjh8+4qncwcmGivnM6ytbpQT+k/jEOeXG2bQhjojvnXN3FazGCEFXvpuIBcJVfaIJS9YBCMOzzrAtO0+k2hWnOQIhAOC4NVbo8FQhZS4yXM1M86kMl47FA9ui//OUfbhlAdw1AiEA2DBmIXnsboKB+OHver69p0gNeWlvcJc9bjDVfdLVsLcCIQCPtV3vGYJv2vdwxqZQaHC+YB4gIGAqOqBCbmjD3lyFLQIgA+VTYdUNoqwtZWvE4gRf7IzK2V5CCNhg3gR5RGwxN58CIGCcafoRrUKsM66ISg0ITI04G9V/w+wMx91wjEEB+QBz"
rv = NSS_NoDB_Init(".");
slot = PK11_GetInternalKeySlot();
ATOB_ConvertAsciiToItem(&der, pubkstr)
spki = SECKEY_DecodeDERSubjectPublicKeyInfo(&der);
SECITEM_FreeItem(&der, PR_FALSE);
pubkey = SECKEY_ExtractPublicKey(spki);
char *pvtkstr = BASE64_ENCODED_PRIVATEKEYINFO;
SECItem nickname, pvt_der;
nickname.type = siBuffer;
nickname.data = "pvtkeynickname";
nickname.len = strlen("pvtkeynickname");
ATOB_ConvertAsciiToItem(&pvt_der, pvtkstr)
PK11_ImportDERPrivateKeyInfoAndReturnKey(slot, &pvt_der, NULL,
NULL, PR_FALSE, PR_TRUE, KU_ALL, &pvtkey, NULL);
SECItem encdata;
encdata.len = PK11_SignatureLen(pvtkey);
encdata.data = (char *)calloc(encdata.len, sizeof(char));
SECItem plain_data;
char testdata[1024];
int i;
for(i=0;i<TESTLEN;i++)
testdata[i] = 'a';
plain_data.len = TESTLEN;
plain_data.data = testdata;
if(PK11_Sign(pvtkey, &encdata, &plain_data) != SECSuccess){
...
}
SECItem decdata;
decdata.len = SECKEY_PublicKeyStrength(pubkey);
decdata.data = (char *)calloc(decdata.len, sizeof(char));
if(PK11_VerifyRecover(pubkey,&encdata,&decdata,
NULL) != SECSuccess){
...
}
fprintf(stdout, "decrypted and recovered data: %s \n", decdata.data);
now the test code failed in PK11_Sign() with 8192 error,
and as i have said error code description about this errno is
senseless.
I also split the plain_data into subtoken, whose length is < modulus len,
but had the error too.
I try to use PK11_PubEncryptRaw(), which can encrypt the plain_data
smoothly,
but i don't want to do any padding thing, so i also try to use
PK11_PubEncryptPKCS1() in above codes, and also got same error(8192)
i also test the code here:
http://www.mozilla.org/projects/security/pki/nss/sample-code/sample5.html
i just replace PK11_PubEncryptRaw() and PK11_PubDecryptRaw() with
PK11_PubEncryptPKCS1() and PK11_PrivDecryptPKCS1(), and got following
error:
Public Key Modulus 64 bytes
Buffer being encrypted =
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJK
Encrypt with Public Key failed (err -8192)
why?
Note: for PKCS #1 specifies different padding rules for Sign/Verify
versus Encrypt/Decrypt. For the former the padding character is a
constant (I think ff, but I'd have to check to be sure), while the
latter pads with random non-zero data.
Also Note: A full PKCS #1 RSA signature is not only PKCS #1 padded,
but also wraps the digest which it is signing with a DER wrapper which
includes the OID value of the hash used to generate the digest.
PK11_Sign does not add this wrapping on it's own, and
PK11_VerifyRecover does not strip it.
bob
can anyone give me some examples or hints? thanks
in advance
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
------------------------------------------------------------------------
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
