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 &/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.


  • 1
    $\begingroup$ Never do bulk encryption with asymmetric cryptography. Asymmetric cryptography is typically used to encrypt a symmetric key which is used to do bulk encryption. $\endgroup$
    – mikeazo
    Apr 29, 2014 at 18:31

1 Answer 1


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.

  1. 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.

  2. 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.

  • $\begingroup$ The algorithms for #2 would be along the lines of RSA+AES or ECDSA+AES. $\endgroup$
    – Artjom B.
    Apr 29, 2014 at 18:51
  • $\begingroup$ How would 2 be more secure than 1? As in what is the attack vector I am protecting against? And yes, I need to raise the bar slightly as an urgent measure but what would be a good, longer term way to solve this problem? $\endgroup$
    – owagh
    Apr 29, 2014 at 18:51
  • $\begingroup$ Oh I can see that 2.) is what SSL/TLS seems to be doing... nice! i always thought it was RSA through and through $\endgroup$
    – owagh
    Apr 29, 2014 at 18:54
  • $\begingroup$ @owagh, for a good long, term solution. I suggest you post a new question (probably on IT Security as this site is more about the theoretical underpinnings of crypto an not necessarily the day-to-day use, IT security will probably be better for day-to-day use stuff). Give a good, clear, concise description of the attacks you are worried about, and you should get some answers on options to mitigate them. There is no silver bullet for this problem, but some options with different tradeoffs. $\endgroup$
    – mikeazo
    Apr 29, 2014 at 19:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.