> From: [EMAIL PROTECTED] On Behalf Of Shaun R. > Sent: Monday, 17 November, 2008 18:50
> I'm using RSA to encrypt/decrypt some text. I encrypt the data using the > private key and then decrypt it using RSA_public_decrypt(). One thing i This is not really encryption, because it does not provide confidentiality. Sending with the RSA privatekey operation (i.e. exponent 'd' in the usual notation) and receiving with the RSA publickey operation 'e' does provide signing/verification functionality, and because it is mathematically similar to the encryption/decryption primitives it is often lazily called that. > noticed was that if the data was not encrypted using the correct > private key > that RSA_public_decrypt() will just set the output to giberish. Is there Right. The basic RSA primitives (exponentiation to d or e modulo n) provide almost no error checking; they work for any numbers in the range k .. n-1 where k is a fairly small number but large enough not to remain linear. (Given the usual computer application to arbitrary bit strings, there is some range corresponding to the numbers n .. 2^bits -1 that can typically be caught as erroneous, but not with high enough probability to be safe.) > anyway to check if the public_key is the correct key to decrypt that data > before actually decrypting it? That way i can bail out early and say > invalid data file rather than parsing through a bunch of giberish? > There are two general approaches to this. Add redundancy to the data, called padding (although in some cases, like OAEP, that name is slightly misleading). The desired properties and thus design of padding are different for sign/verify than for encrypt/decrypt. The common sign/verify padding, type 1 in standard PKCS#1 from what was then RSA Labs, basically just adds enough bytes (octets) with a fixed value 0xFF that a garbage value due to a wrong key, which is effectively a random number, has negligible probability (one in zillions) of falsely matching. Protect the public key(s) (used for verify or encrypt) against modification, either malicious (tampering, substitution) or accidental (bugs, mistyping or misconfiguration, etc.). The common way is to embed or wrap the pubkey in a certificate, which is signed by a Certificate Authority (CA for short). When processing, you check the signature on the cert; if it is valid, you trust the data in the cert, which includes the pubkey, is correct. (There are actually two branches to this: based on who the CA is, you trust they verified the requester's identity and possession of the privatekey before issuing the cert, and you trust the digital signature on the cert to prove the cert you are holding is the same bit-for-bit as the CA issued. In general to rely on a cert you also need to check if the CA has revoked it, but that applies only to the first branch: the conditions for issuing a cert are no longer met, because the requester has been found fraudulent, or has become unauthorized, or their privatekey has been compromised. A CA needn't revoke a cert because a copy of the cert is tampered/damaged; that can be fixed just by getting/distributing a good copy of the cert.) Also note that it is not usual to directly RSA-sign/verify your real data, because of the limited number of bits that fit (after padding) in one RSA primitive operation. The usual practice is to take a secure hash (like SHA1, or SHA-newer, or MD5 but that's teetering) of the data, and RSA-sign (with padding) the hash; the recipient takes the same hash and RSA-verifies it. Similarly for encryption the usual practice is to encrypt the data with a symmetric algorithm (like AES, DES or better '3-DES', RC5) and a random key (DEK), and then RSA-encrypt that DEK (with padding); the recipient RSA-decrypts the DEK and then uses the DEK to decrypt the data. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
