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
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.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
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)
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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
