I’m developing a method for encrypting game data files which will be used in a game engine that I’m creating. The game data file will be encrypted with a private key and decrypted once loaded into the game engine.
The private key will be set manually in the engine (as a const) so that it is compiled into the engine. The trick, however, is obfuscating it in there so that your average Joe Bloggs can’t (easily) find the key simply by disassembling and reverse-engineering the code.
struct Example {
u_int8_t random1;
u_int64_t segment31;
u_int8_t random2;
u_int8_t random3;
u_int64_t segment3;
u_int64_t segment14;
// Etc
};
My idea is to store the key in segments which are jumbled together with randomly generated bytes. My question is this:
Is there any way to randomly generate a number in a C++ macro? The number must be randomly generated at compile time (or the random values each set to a random user-selected value), so any runtime functions are no good.
I’m open to any suggestions if there is a better way of doing this, but I definitely want the game data files encrypted with a private/public key pair, and the public key kept as private as possible.
Since you are generating a constant random number at compile time which will become baked into your program, I don’t see a difference between that and simply hard-coding a random number (of your own choosing) into it yourself. I suppose with a macro you get a different random number with each compile. Is that really so critical?
I recommend doing something simpler: If the key were simply ASCII text (bits are bits, right?) you could use an inocuous-looking diagnostic string as your key and no one would notice it.
Still, security by obscurity is generally frowned on by experts in the field (they do a lot of frowning). If you are really doing public key encryption, it is perfectly OK to have the public key exposed. That is the point after all. It is the private key which must be kept secret.
If you really want to do this, then I would look at a random number generation algorithm, and unroll an iteration of it into a (large) macro that essentially takes a seed and evaluates to a large expression that yields a pseudorandom integer as its result. That should do it. If the seed were somehow derived from an unpredictable thing like the time of the compile (
__TIME__), it just might work.