Sign in to follow this  
George Jurcich

How to store encryption keys?

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
Other point: if you want to store the keys, I think you should store them as encrypted hashes.
There are many algorithms to create these hashes, SHA-1(Secure Hash Algorithm)is one of them.
See www.codeproject.com/cpp/csha1.asp to see what I mean.
This makes more more difficult to retrieve the keys.

Share this post


Link to post
Share on other sites
If you're making a freeware product/shareware product, use something simple like XOR encryption with a hardcoded key.

If you are making a commercial product, mangle the package decryption key into the product-key. The user buys your product, and activates it with the key. Unmangling the key will return all the data that was stored in the key, including the data file key.

This will take away the key from the actual file, and you can still have different keys per package(Using the correct algorithm, you can sort of compress the keys/username into it. Perhaps a simplified ZIP algo will do).

Toolmaker

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this