The goal of the kind of encryption I''m really intrested in is just to do a good job of encrypting single player game data files. I''ve read about public key RSA algorithms and such. But this seems like its mainly suited for encrypting network data. For single player art/game data assets etc though, what is the best way to handle encryption? I was think a multiround system something like this... XOR based on key (128bit enough?) Permutation (random seeded based some how on key) Substitution boxes (not really sure on these see below) Now I''ve read that a good system gets better with each different round, something like 8-16 in popular algorithms. Anyway, if anyone can explain to me the subsitution box thing(ie how it would work in code) I''d really apprieciated it. Also any general ideas on an overall encryption for single player game data and other assets. Here is a breif quote I found on it in a general encryption article... "A popular method of implementing a substitution function is to use a construct referred to as a substitution box, or an S-box. The S-box function takes some bit or set of bits as input and provides some other bit or set of bits as output. It makes use of a replacement table to perform the conversion. These reference tables can map more than one input to the same output. As a result of this truth, a hacker cannot take the output from an S-box and figure out which of the many inputs may have been used to generate the output."

There is no way to correctly handle encryption for single player data. You have to uncompress the data on the player's machine to play the game, and once it's been uncompressed he/she can trivially read and edit the data.

Since you're dealing with an untrusted system, use something minimal, if you feel you must encrypt at all. There will be easier ways to defeat your security than cracking the encryption.



[edited by - cheesegrater on April 20, 2003 9:21:02 PM]

>There is no way to correctly handle encryption for single player data.
I can second that. It''s amazing to see how people cheat. I''m not even talking about single player games. There seems to be almost nothing you can do to stop people from cheating at online games, where you''d think it would be much harder than single player games. I only know the tip of the iceburg when it comes to how people write cheats for online games, and even the little I know is scary. To some of these hackers, you might as well save them a few days work and email them your source code.

With single player games, do a little XOR encryption if you want to keep out most people, but someone with a moderate level of talent will be able to rip your game apart and do just about anything they want, and there''s nothing you can do about it, so don''t spend too much time on it.

If you''re using windows, check out the CryptoAPI

Blowfish is simple to use and implement. The reference code might be in need of optimization, if speed is important, but that''s pretty much it.

Regards Mats

quote:Original post by CheeseGrater
There is no way to correctly handle encryption for single player data. You have to uncompress the data on the player's machine to play the game, and once it's been uncompressed he/she can trivially read and edit the data.

Since you're dealing with an untrusted system, use something minimal, if you feel you must encrypt at all. There will be easier ways to defeat your security than cracking the encryption.



[edited by - cheesegrater on April 20, 2003 9:21:02 PM]

I don't believe that the data can be edited so 'trivially' as you make it sound. It is not that easy to find out where and what to read in memory with most data types. There is no need to make temporary copies of the decrypted files on disk (unless the libraries restrict) so its not as simple as just opening a file and readin it.

Having said that, there are many crackers who could still easily get to the data. Although having your files compressed with blowfish or something, and by managing to 'hide' the key in your executable, it is a lot more secure.

[edited by - Tylon on April 21, 2003 6:28:45 AM]

quote:Original post by Tylon
I don''t believe that the data can be edited so ''trivially'' as you make it sound. It is not that easy to find out where and what to read in memory with most data types.

It is trivially simple. All you need is a decent debugger - Try it out sometime.

How do you think cheat programmers develop those in memory patching programs to modify games at runtime?

Look at Diablo 2, I use to love that game until people figured out how to modify the packets. Then all the dupes came and took the fun out of it ahhh poor Diablo

-UltimaX-

"You wished for a white christmas... Now go shovel your wishes!"

quote:Original post by CheeseGrater
It is trivially simple. All you need is a decent debugger - Try it out sometime.

How do you think cheat programmers develop those in memory patching programs to modify games at runtime?

Well yes, however I still wouldn''t consider it that trivial. The person will have to know what he is doing, and understand assembly etc. Not something that your average user can do.

Really that was what my point was. I by no means want to even attempt to keep out all the "l33t hackers" out there. Just something to keep out the average user and maybe even a few would be hackers.

Anyway thanks everyone there advice. I just implemented something simple, if I decide I really want to screw with hackers maybe I''ll try something a little more heh.