What cryptographic paradigm is appropriate for this use case? This is a very newbie question...

I have to quickly implement a solution for our application that works like this... We have a binary executable that is given a configuration file. I need to encrypt the configuration file such that a non-trusted user can be given the binary and the encrypted config file (and maybe a public key or something) and he should be able to run the binary with the encrypted file. We're not concerned with the user disassembling or reverse-engineering the binary itself for now.

Could you suggest a cryptography paradigm &amp;/or c++ crypto library that will allow me to do the above? I was thinking of encrypting the config files with a public key, the private key of which would be embedded in the executable but I'm not sure if that is a secure way of doing things.

Thanks
At least you understand that by embedding a key in the software that someone will be able to reverse engineer the binary, extract the key, and decrypt the file. Or they will find the decryption code, put a break-point after it, and dump the decrypted memory.

Since that does not concern you at the moment, you have a few options.


Generate a random AES key, encrypt the file with that key, embed that key into the source code, decrypt the file in your code and store the decrypted information in memory. 
Generate a single private key and an AES key. Encrypt the AES key with the public key. In your code you can decrypt the AES key with the private key then decrypt the file with the AES key.


Of those two, 1 seems simpler. Of course in either case, you run the risk of a single user finding the decryption key and writing a simple script that will work on all of your customer's machines.

To "fix" that issue, you could generate a new key (be it AES or private+AES) for each binary you ship. There are still ways to develop a script that would read the binary, extract the machine specific key, and do the decrypt. It will be harder though, but doing this also means you need to track more keys.

Since it sounds like you are not worried about sophisticated attacks, only want to raise the bar slightly to prevent casual users from getting your configuration files, I'd go with #1. Just make sure you understand all the risks.