Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

hello2k1

Encryption

This topic is 5927 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Right now I am working on constructing an encryption mechanism into my game''s gameplay packets. Each server must be able to suppost vast quantities of users, but yet still be secure (since we''ll be using UDP). We are already implementing packet sequencing, but are exploring the option of adding an encryption agorythm into the mix. Now, havign said that, I would liek to call upon the encryption experts in the house to answer me a little question; How could an encryption layer be implemented in which the key cannot be derived from knowing the encrypted information? eg. If the encrypted packet 00 FF 00 is intercepted by a hacker which knows that the packet contained "00 FF 00" prior to being encrypted, how could I stop this hacker from obtaining the encryption key? The "XOR method" clearly fails in this instance: Packet: 1001 0010 0111 XOR Key: 0001 1011 1100 = New Packet: 1000 1001 1011 If I were to know that the original packet was "1001 0010 0111", I could easily obtain the key, and use it to decrypt all the other packets, or even inject packets into stream. This is demonstrated here: New Packet: 1000 1001 1011 XOR Packet: 1001 0010 0111 = Key: 0001 1011 1100 Thank you.

Share this post


Link to post
Share on other sites
Advertisement
Change the key each time a packet is sent. You could base the key on the timestamp, packet number, a checksum of the information in the last packet, etc (of course some of this only works with guaranteed delivery since both sides need the information that is required to generate the key).

***500 errors***

Share this post


Link to post
Share on other sites
Hmm, I like the idea of changing the key, but using a timestamp, or anything involving the previous packet wouldn''t work too well with UDP. Changing the key might also prove to be too much pressure on the servers.

I was more thinking about an algorythm that isn''t susseptable to that kind of manipulation, but will not take up more than 3-6 cycles per byte (well really per 8 bytes using MMX).

Share this post


Link to post
Share on other sites
you want fast or do you want secure? you have to decide, because many secure systems rely on their slowness to slow would be crackers.

you could use md5 checksums like quake3 (ie one way hash of the data, thus tampering with the data will be noticed). of course the hacker could figure out the key being used for the hash since he has access to it (ie the client) thus you need to change it. in fact any system is flawed since they are designed so the cracker dont have the key. with games he does.

i mean why intercept packets when i could just intercept function calls?

your 3-6 cycles per byte is VERY fast and allows only 3 ops depending on what they are. i suggest using a simple method, maybe tea (tiny encryption system), but again many systems are not highly parrallel and you cant use mmx in any benefit. its just happens to be that the math dont allow such things which again makes them more computential secure since more bytes determine the out come (ie the more you can parrallelize the process, the less the bytes will contribute as a whole to the encryption and uniqueness).

i suggest doing some research since you are really asking for something thats secure and fast, which wont happen.

basically you CANT prevent them from getting the key. if he is playing using a client that can encrypt and decrypt the packets he has the key.

Share this post


Link to post
Share on other sites
It depends a bit on how important the security is for you. As you mentioned, using a simple XOR is not going to cut it, so you''re best option is probably to go for a well-known algorithm.
If you have the money to pay for a license I''d suggest going for RSA for public-key encryption and possibly RC5 for private-key encryption.

Basically you''ll want a combination of public-key encryption and private-key encryption. The client and the server should use a modified form of the Diffie-Hellman protocol in conjunction with public-key encryption to generate a unqiue session-key with the private-key encryption system that will be used for the duration of the current login.

If you don''t have the money to pay for a license, but still want to publish the product you''ll have to go for some free encryption-system. I don''t know of any free public-key encryption systems, but ElGamal is a freely available private-key encryption system (although it has the distinct disadvantage that the cipher-text is twice as long as the plaintext).

Seeing as speed is of a prime concern I''d suggest that you either use a stream-cipher (none of the ones I''ve mentioned above are stream ciphers), or a block-cipher in counter-mode.

In any case, the only way to get security is to sacrifice speed. So you''ll have to think carefully how much you really need the security of a good crypto-system.

-Neophyte

Share this post


Link to post
Share on other sites
What you''re worried about is called a ''Known plaintext'' attack, and they are very difficult to defend against. They''re very commonly done, though, because TCP headers, Word document headers, etc have a very widely known format. The usual tactic is to take the hit and admit that the attacker will probably get the key for the blocks he knows the plaintext to.

So, that means you need a keystream that modifies itself as transmission continues.

What you want is something like the DES''s Cipher Feedback or Output feedback nodes, which make each block''s encryption dependant on all previous blocks. Plaintext doesn''t help you out here because you need all the plaintext up to a specific point to mount an attack. Encrypt random garbage for your first block, and you''re all set.

Check http://www.tropsoft.com/strongenc/des.htm for an outline of the various DES modes of operation.

Anyway, as has been pointed out, it''s always easy to get the plaintext out when you''ve got access to the client machine/program. Don''t use crypto for anything but protecting against man in the middle attacks or server spoofing. Anything else is pretty much a waste of your time.

If you''re worried about compromised clients, all you can do is compute all the important stuff on the server and forget the client.

Share this post


Link to post
Share on other sites
quote:
Original post by Neophyte
RSA for public-key encryption and possibly RC5 for private-key encryption.

...

. I don''t know of any free public-key encryption systems,



Yes you do!

The RSA patent recently expired. Immediately afterword, the owning company placed the algorithm in the public domain, so there are now no patent _or_ copyright restrictions on RSA.

Since the Diffie-Helman patent expired in ''97, that means that all the elements of a good public key cryptosystem are freely available to the public.

Share this post


Link to post
Share on other sites
Hmm, I was more hoping for a math discussion on the topic, rather than a "it can't be done" flamewar. If you think I'm crazy, keep that to yourself, and for everyone else, how about we out our heads together to make a method that's not succeptable to what CheeseGrater refered to as a "Known Plain Text" attack.

Right now I'm thinking that using two keys instead of just one might do the trick, since a hacker would need to know all but one input to get that one input. ie

Packet: 1011 0101 1101 XOR
Key: 0110 1011 0100 XOR
2nd Key: 1110 0011 1001 =
Result: 0011 1101 0000

Now, even though the hacker knows that the packet prior to encryption was "1011 0101 1101", the key cannot be extracted. ie.

Result: 0011 1101 0000 XOR
Packet: 1011 0101 1101 =
Not Key: 1000 1000 1101

So far I can't think of any flaws in this method other than it being slower, and the fact that two keys are required. Is there anyone that sees a flaw?

Nevermind, just found that it's suseptable to the same hack.

[edited by - hello2k1 on July 26, 2002 11:31:53 AM]

Share this post


Link to post
Share on other sites
Wasn''t there this big parrallel computing thing years back when people argued for a 128-bit standard for encryption? Back then I believe 46-bit was the standard. Wouldn''t that be good enough, or is the computation expense the same between them? I don''t know too much about the history or implementation, but it might be good to research something that took months for thousands of people to crack.

Share this post


Link to post
Share on other sites
Yes, multiple key schemes can often be reduced to a single key, even with more complex types of encryption than what you''re using.

The fact is, the technique you''re using (XOR against a set length repeating key stream) is inherently flawed, and the _only_ way to secure it is to lengthen the key stream. Manipulating a repeating key of the same small length isn''t going to help matters.

You need to come up with a crytographically strong pseudo random generator (such as DES, Blowfish, Triple DES, the AES, etc, etc. NOT rand() ) and use that to generate your keystream.

Then, to protect against a known plaintext attack from someone who is savvy to the ways of private key block ciphers (Admittedly, not a whole lot of people, but at least a few people on this board!) you need to set up a feedback implementation like the ones I mentioned above.

I highly recommend Blowfish. It''s a nice little block cipher that''s got freely available source, and it encrypts data at only 18 clock cycles per byte on a Pentium. It''s a drop in replacement for DES, so you should use it like the Cipher Feedback DES mode to prevent known plaintext attacks.



Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!