I need to store a key (symmetric-key cryptography) within my C++ application binary (based on OpenCV) so that the key as unidentifiable as possible. Can someone help me choose the key so that is secure and it will be difficult for an attacker to find the key in the binary?

If I choose plain text (regardless of length) then this will be saved as text in my binary and will be easily identifiable, am I right? So I probably want to select a key that looks like a generic binary content.

I guess having multiple keys that will be used in predefined order may also make it more secure since the attacker has to find all the keys (which may be stored in different places within binary).

I need to choose this type of protection because of the nature of my application. I accept the risk of an attacker finding the key - in such case I will use new key and new application binary - but I do not want to do this very often (hopefully never).

I know it is impossible to have 100% key security this way but I want a basic level of security so that the attacker needs to have some knowledge at least.

  • As text? Were you planning on storing the key in its hexadecimal text form, or as the binary bits that the text represents? Commented Sep 8, 2019 at 17:29

3 Answers 3


Basically, you can't.

What you look for is DRM by any other name, and history has shown time and time again that DRM isn't effective. Any skilled attacker in possession of the binary is therefore also in possession of the key, regardless of how well you hide it.

Even if you were to store the key on your server and load it dynamically from the internet, the attacker can either intercept it as it is being transmitted, or dump the key from memory once it has been loaded.

In fact, the attacker doesn't need the key at all, since once it is being used to decrypt some data, the attacker can just dump the decrypted data from memory, once decryption has finished.

  • I just added a paragraph that I know it is impossible to have 100% key security this way but I want a basic level of security so that the attacker needs to have some knowledge at least. Would you have a quick recommendation to have a basic level security by choosing a non-trivial key?
    – Kozuch
    Commented Sep 4, 2019 at 9:53
  • 1
    @Kozuch I could recommend you any number of things, but they would all be snake-oil ultimately. I can't ethically recommend any kind of obfuscation, knowing that it's purpose is to give a false sense of security. But let me ask the other way around: Why do you want to encrypt data for a user and selectively decrypt it for the user? What exactly are you trying to prevent?
    – user163495
    Commented Sep 4, 2019 at 9:55
  • I will sell USB devices (3D sensors) which each is calibrated and want to protect my calibration procedure by encrypting the calibration data (this data is specific to every device). There are about 10 pcs or more of float type values (real number) to protect. I can choose not to encrypt but make my "binary data format" instead - but this will not add any "security" either. Maybe add some "false" floats for confusion. The C++ application is non trivial (some math, analytic geometry...) so it will be hard to reverse engineer anyways. The product of the application is a stream of 3D point cloud.
    – Kozuch
    Commented Sep 4, 2019 at 10:14
  • 3
    @Kozuch "I want to prevent competitors from stealing my work" is a legal problem, not a security problem. You'd be much better off contacting a lawyer and check your options that way. This would be a way better option than adding a few pieces of obfuscation. Or let me phrase it this way: I'm pretty certain Sony could make a new PlayStation that can play Xbox games as well, if they tried. Guess what is holding them back? It's not obfuscation, that's for sure.
    – user163495
    Commented Sep 4, 2019 at 10:17
  • @MechMK1 I am not sure that the Sony PlayStation is a good example here, as this would be large corporations interacting in a very public way. Not much good to Sony to support XBox if they didn't tell their potential customers about it. I don't think that's a close match to someone copying this USB device. Commented Sep 8, 2019 at 17:21

Sooner or later an attacker will get access to the binary code of your application including your embedded password and thus will know the password. It is not serious to think that, if you scramble it, an attacker will not get the password. What are you trying to do is security by obscurity.

Remember Kerckhoffs's principle 2.

It should not require secrecy, and it should not be a problem if it falls into enemy hands;

What can you do instead? Put you encryption key outside of your application, so that application can read it when it needs.


Text? You are storing the key as binary, not as the text hexadecimal representation of the binary bits, right?

There's security, and then there's making things slightly less convenient for an attacker. It sounds like you are assuming that they have a copy of the program and are reverse-engineering it. Whatever you do, what is to stop them from simply copying that part?

If simply trying to be a bit more difficult, there are trivial games such as:

  • Shuffle the order of the key bytes and bits

  • XOR with an incrementing, decrementing or other numeric pattern

  • Spread key de-obfuscation across multiple code areas Which should slow them down by one to a few hours.

This only works as long as the attacker has insufficient motive to figure out the puzzle - and does not come up with some other approach to building a similar device.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .