> From: [email protected] On Behalf Of redpath > Sent: Tuesday, 11 September, 2012 09:05
[in previous post] > Code is presented without error recovery such as checking > the file point > for nil > as to be clear to what is being executed. Sure there is > plenty of code with > error recovery > in the actual test case. <snip> In that case, it's best to post code with some indication of the omitted error handling like a comment, or to reduce it to assert() rather than omitting it. Then readers can know any problem you have is not lack of error checking. > My Situation: > Put simply I want to make sure the public key is only in the > certficate I > hand out; hence > why I did not use the public/private key pair PEM in sample > code to verify > that I only have the > pubic key in a file in the test skeleton code. > > So in summary I currently have the > following right now but this can be fixed. > > openssl genrsa -out test.pem 2048 > openssl rsa -in test.pem -pubout -out testpublic.pem > openssl req -new -key testpublic.pem -inform pem -X509 -days 3650 -out > testpublic.cert > > It should be this below and only the public key will be in the X509. > > openssl genrsa -out test.pem 2048 > openssl req -new -key test.pem -inform pem -X509 -days 3650 -out > testpublic.cert > To be exact: the key in the X509 cert will be only the public half. The X509 cert will contain other information besides the key (although you may not care about and use that information). > Right now I use PEMs and an RSA *rsa structure to encrypt/decrypt > > PEM_read_RSAPrivateKey(fp,&rsapriv,NULL,NULL); > PEM_read_RSA_PUBKEY(fp,&rsapub,NULL,NULL); > RSA_public_encrypt(strlen((char > *)name)+1,name,to,rsapub,RSA_PKCS1_OAEP_PADDING); > RSA_private_decrypt(128,to,result,rsapriv,RSA_PKCS1_OAEP_PADDING); > Without the separate publickey file and rsapub object, you can use rsapriv for the public_encrypt call. The publickey call will use only the publickey components from the object. > and can use this to get the X509 object I created. > > X509 *cert=PEM_read_X509(fp,NULL,NULL,NULL); > Yes. > > > Your saying I could use this EVP high level API function to > get the public > key out of > the cert I created. > EVP_PKEY *evp = X509_get_pubkey(x509); > and of course I could use this too to verify that the X509 is good. > X509_verify(x509, X509_get_pubkey(x509)); > That only verifies the signature, which proves the data in the cert wasn't tampered with or damaged. It doesn't prove a crook didn't substitute an evil but correctly-signed cert. Although if this cert (and the key in it) are never used to encrypt data, the crook can't gain anything by either substitution or tampering. > but the X509_get_pubkey(x509) returns a EVP_KEY structure > and it is not clear to me what the corresponding API function for > > RSA_public_encrypt(...,RSA_PKCS1_OAEP_PADDING); > Looking more carefully, I DON'T think EVP does this unusual case. EVP_Encrypt* and equivalently EVP_Cipher*(,,enc=1) are symmetric. EVP_Seal* handles the normal two-level case (symmetric-encrypt data + publickey-encrypt DEK) but as far as I can see not the "raw" case. So, use the other approach: EVP_PKEY_get1_RSA and lowlevel calls. > would be. Basically I have a large file and only want to encrypt some > areas of the file as the file should not be in the clear that could > simply be copied and sent around. You have to have the infrastructure > to view it that being the public key and something to read and display > the file. The file does have a signature to verify trust and thats > good but clearly there is some data we do not want to have > open. It is > really a level of obscuration is this aspect. > If it's RSA-encrypted, you can't decrypt with the publickey. > Clearly there should be a simple step solution to load a > pubkey (X509) and > use to decipher. Using the PEMs it is clear and very clear as to the > structure saying RSA *rsa. > If you mean encrypt, yes. You can't decrypt RSA with the publickey. But maybe you don't really want encryption. If you RSA-sign (the actual data i.e. lowlevel) it is mathematically similar to encryption but using the privatekey. (Without padding it would be the same, but without padding for smallish values I vaguely recall there were attacks and maybe breaks -- before the issue of PKCS#1 which Wikipedia puts in 1993.) You can "recover" the data from the signature with the publickey. (Most software won't do lowlevel RSA signature recovery, but most software won't do lowlevel RSA decryption either, so you will probably be writing the software in either case.) That signature is not readable by an unaided human, but is not really secure either -- anyone with the publickey and some working brain cells can "decrypt" it, and if you give the publickey to more than one or two other very close people, usually a crook can get it. But if you only want to discourage people from reading this data and not actually prevent them, you don't really need publickey or modern crypto at all, you could do something simple like ROT13 or a classic Vignere. > The knowledge I draw from is O'Reilly "OpenSSL" and clearly has > examples using the RSA structure and some other chapters on > using random > numbers and > EVP for enveloping which is what I not want to do. > > Our major trust point is the signature of the file (ECC) but > we do want to > encrypt some areas of the file as to obscurate and not have > information in the clear for this custom system. No need to encrypt > the whole large file just some sensitive areas that require need to > know privileges. > It's not clear if you mean this as a requirement (file must be readable except for sensitive parts) or an optimization (whole file can be encrypted, but encrypting parts is faster/cheaper). If the latter, you should be aware that lowlevel RSA encryption and decryption of multiple chunks of your data will be *much* slower, like 100 times slower, than the conventional approach of symmetric-encrypt the body and RSA-encrypt the DEK. That's exactly why the conventional approach is conventional. > I assume the best way to hand out the public key is the X509 > cert I created, > if you have better recommendations they are most welcome. Then I need > the public key to decipher to chunks of data from the > document that has a > signature. > Given this key will probably only be usable with software you distribute, it's your choice what the software accepts. An X509 cert is a convenient and standard form, but openssl can as easily use its PKCS#1 and "PUBKEY" (SubjectPublicKeyInfo) formats. But if you want to port your software to say Java or maybe dotNET, then X509 becomes much more convenient. <snip rest> ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
