I'm having trouble figuring out how to store the encryption key for my package files. It's a toss up between 2 ideas. Idea 1: Have the packer generate a random key for each package and hide that key inside that file itself. Pros: Each file would have a different key. Cons: Each file contains the key! Idea 2: Have a predefined key and store it in a seperate "Key File" or inside the executable it's self. Pro: Removes the key from the file. Cons: Each file has the same key, Key would have to be stored in a seperate file. I'm leaning towards idea 1. This way each file would have a different key and if someone cracks the first file, they'd have to do it all again for another. But I get this uneasy feeling storing the key inside the file itself. Idea 2 would mean every Package file would have the same key. So all someone has to do it crack the key file and they'd get all the data. Or if it was in the executable they could just grab it out of there. Should I go with Idea 1? Does anyone have any better ideas? I'm fairly new to encryption so any help would be great! How are key's normally handled?

Im confused..... what is your goal in encrypting the package files?

the other option is to not bother with encryption.

If it's a "wrong hands" problem then you give the "right hands" the key through a secondary means (email, phone call, etc) and leave the key out of the data files. You then provide a prompt to enter the key.

If you want to encypt your data files so that nobody can read them but your program then you need to

a) write a custom unpublished algorithm for encyption
b) store the key at a known point in the data

a will be dissassembled if enough people care and b will be found by tracing your program as it retrieves the key

This is why the DMCA exists (DVDs use key storage method you're looking at implementing). Encypting data except for the "wrong hands" scenario is retarded and can only rely on legislation to not be broken.

You're better off simply not bothering with encyption unless you're working with critical data. Stoping someone from messing with game files isn't a worthwhile venture.

At some point, your program has to decrypt your data, so a hacker could either grab the key from that point in your program or just steal the data as it's decrypted. It's like encrypted mp3 files; you can always record them in an unencrypted version whilst the encrypted version is being played. There's nothing you can do about this. The most powerful companies in the world can't get the protection you're looking for, except through non-technology means like the DMCA as mentioned. Long story short: you cannot prevent a determined hacker with our current technology, just slow them down a bit.


Why do you want to protect your files anyway? If somebody steals your artwork and uses it, you can sue them for copyright infringement. Plus, you could try and encourgage modding, which made Quake and other games so popular.

If you are encrypting content with the intention of protecting your art, etc.. from the recipient you are out of luck. Both the encryption algorithm and the encryption keys are stored on the client which means that it is simply a means of disassembling the application to identify where the keys are located.

If you want to set your game up in such a way that you can only play approved modules etc, with it then the other alternative is to use assymetric encryption.

You generate a private key that only you have, and distribute a public key with the game.

Each time you release an update create an archive which contains the files to be authorized, and a manifest containing digital signatures for each file which are generated with the private key.

When you are loading the files check the signature for each file as you load it, and if the signature does not match then refuse to load the file, terminate the application, or insult your users lineage to your preference.

This is a fairly lightweight way to protect your client from most attackers, however someone can still hack the client to ignore the signature checks.

An important concept from a security perspective is that if it is running on the clients machine you cannot control it or protect it.

Thanks for all the replies.

Sorry, I should have explained things a little better in the OP. I do know that if someone really wants to get at the files they can. I'm not trying to encrypt content or art. I'm not worried about someone stealing that stuff. I know your gonna say why protect the files at all then. Well idealy I'd like to go shareware eventually with this.

It's a smaller hobby project of mine, making a little multiplayer game. I figured if I could package the in-game scripts together and use a simple XOR encryption on them with a larger key instead of a single hardcoded offset. It would make the cheaters life much, much more difficult and then the client would do a checksum on that package to see if it was tampered with. I'd use to roll out patches as well.

I know people like to mod and I'm not against it in any way. I was trying to beef up a simple encryption scheme to protect the multiplayer experience.

Thanks ChaoticCanuck, I'm going to look into that assymetric encryption. It sounds very similar to what I'm trying to do.

If you are developing solely for Windows look at the CryptoAPI and specifically RSA implementations.

If you want to get more into the nitty gritty of encryption take a look at OpenSSL, but it is much more difficult to work with.