#### Archived

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

# Encryption

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

## 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 on other sites
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 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 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 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 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 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 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 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 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 on other sites
CheeseGrater:
Would you happen to have the formulas that correspond to each of those encryption methods you mentioned? I would liek to disect them to see what makes them tick.. Maybe it''s possible to make an MMX equivalent or modulation of one.

##### Share on other sites
Well, you can get blowfish code from the blowfish site, so I won't bother posting that.

Things like DES and Blowfish use S-boxes for encryption, so they really don't have any formulas anyway. They have instructions like 'exchange bit 17 with bit 48'.

Public key stuff is the stuff that can get away with a mathematical forumla, because those methods are based on a computationally intractable mathematical problem (like prime factoring.)

Cipher Block Chaining is a pretty easy mode to plug blowfish into. It'll do what you want. You'd use it something like this (InitializationVector is a Block of random stuff that your client should have as well as the key.)

Block Encrypt(Block PlainText, Key InputKey) {    static Block OldEncBlock = InitializationVector;    Block EncBlock;    PlainText = PlainText.XOR(OldEncBlock);    EncBlock = Blowfish_Encrypt(PlainText, InputKey);    OldEncBlock = EncBlock;    return EncBlock;}

[edited by - cheesegrater on July 26, 2002 3:01:08 PM]

##### Share on other sites
Hmm, so how would "S-Boxes" be immune to the Known Plain Text hack?

Also, you missed AES.

##### Share on other sites
Forgive my ignorance, but what would be the point of encrypting something you already know the attacker will have access to? If they already have access to it, then why not send it in plaintext, so that the key is not contained in the sent information? And if it is not known which part of the plaintext is known, isn''t this almost tantamount to having been cracked?

Anyway, your double XOR just failed because XOR is associative--XORing the last two then the first is just like XORing the first two then the last. You just need to find an operator that is not associative, or two operators that are not mutually associative.(probably distributive instead)

##### Share on other sites
quote:
Original post by hello2k1
Hmm, so how would "S-Boxes" be immune to the Known Plain Text hack?

They aren't. Your system becomes resistant to those attacks by setting up a system in which knowing how to decrypt one particular block doesn't allow you to decrypt later (or earlier) blocks. That's why you use Cipher Block Chains, or something better than Cipher Block Chains. CBC's are just what I could easily remember from the top of my head. That mode helps somewhat against known plaintext (though plain 'ol DES or blowfish does a good job against that.) It also helps prevent attacks that involve reordering the cipher text, like if someone found the 'Give \$100' encrypted block and tried inserting it in the data stream over and over.

S-Boxes just happen to be how DES and blowfish work. You can read a description of what they do at one of the links I gave. As you read, just remember that DES/S-boxes were originally designed for hardware and not software. Then they should make sense.

I'm not going to paste in the AES algorithm (aka Rijndael) here. Code is freely available, just google for it.

[edited by - cheesegrater on July 26, 2002 4:38:29 PM]

##### Share on other sites
quote:
Original post by Anonymous Poster
Forgive my ignorance, but what would be the point of encrypting something you already know the attacker will have access to? If they already have access to it, then why not send it in plaintext, so that the key is not contained in the sent information? And if it is not known which part of the plaintext
is known, isn't this almost tantamount to having been cracked?

You're assuming the attacker is always the client. Encryption's primary purpose is to defend against people tampering with the datastream along the message's route.

People who are only interested in preventing cheating shouldn't be worried about crypto - it won't help them. Crypto is for defeating people who want to remote control other players, spoof the server to screw with other players, etc.

[edited by - cheesegrater on July 26, 2002 4:36:29 PM]

##### Share on other sites
Oops, just noticed that you were refering to Anon Poster.

If the hacker has access to the clients computer, other security measures are put into play.. But what I'm trying to prevent is the hacker intercepting, or spoofing the packets of another user.

If the hacker manages to get a program running on another client's computer, there is almost no hope. The only thing stopping them would be the user's common sense (ie. mouse moving by itself means virus), and a few tricks I picked up back in my hacking days.

Wouldn't doing something like shifting the mmx register, then multiplying be a simpler form of CBCs?

[edited by - hello2k1 on July 26, 2002 5:51:38 PM]

##### Share on other sites
But if the attacker is not the client, how would the attacker know any of the plaintext of the message?

##### Share on other sites
Because they have a client too, and could easily determine what common packets are.

##### Share on other sites
So don''t encrypt the portions you know will be in common between clients.

##### Share on other sites
hello2k1, first off most "hack" attempts wont be for messing with another client or players. whats the point? they would have to be in the position to sniff packets. thus on the same lan connected via a hub (or ARP flooded switch), on a router (most ppl dont have access to them), etc. basically its very difficult to be in the position to mess with players. for instance i could NEVER be able to mess with other player packets since i would never recieve them. sure i could IP spoof and send packets that i pretend originate from some other player (assuming somehow i was psychic and knew the IPORT that the other player was using) since most mulitplayer games i know of never give out client ips. only the server knows them, and other clients dont need to.

assuming the hacker magically able to mess with the packets,a nd you want some encryption to deal with it. if all clients connected use a different key which chenges at connect, there is a small window only in which the hacker could get the key. want to help stop that? use a public key system. this means two keys: private and public. the private key is linked to the cd key or installation media (ie cd serial) so its unique per player. maybe even have the player sign up to get a private public key pair. now each server has there own private and public keys.

key exchange:
server send its own public key. client sends its public key encrypted using the server public key. now the server decrypts the client public key using its private key. hacker only knows server public key, it cant decrypt the client public key.

server to client:
server sends data to client encrypted with the clients public key. the client decrypts using its private key. hacker cant decrypt anything since it needs the correct private client key which he dont have. he cant spoof messages since he needs the public client key which he dont have.

client to server:
client encrypts with its private key and sends. server decrypts with client public key. hacker cant spoof or read since he needs the proper client key which he dont have.

now problems:
if a client ocnnects to a bogus server the server would get the public key and if published hackers could use the key for that particular client to have some fun (spoof server messages or read client messages). the taks though would be matching a client on a legit server to the right key which is pretty difficult since it would require going through all the keys the hacker has on the packets he can sniffa nd hope that one of the keys he has belongs to a player that he can get packets from. this could be "fixed" by using session keys instead of per client keys.

do some research into public key encryption and rsa. its not the fastest algo, but its pretty secure for what you want. ssh uses similar methods. you may wish to do some research on that as well since ssh allows secure communication between a server and client using TCP. the system does not trust either the server nor the client nor the pcs in between. so its designed for what you want.

also when i said the hacker would have the keys already since they would be at the client pc. i meant that most ppl would modify their clients so they could cheat instead of trying to mess up other players. since its pretty diffiuclt (and only a select few) can sniff packets in which they would change to mess up players. the hacker would gain no advantage nor even see the results. on the other hand players could easily goto sites to download cheats that modify how their client works so they could play better.

##### Share on other sites
quote:
Original post by a person
hello2k1, first off most "hack" attempts wont be for messing with another client or players. whats the point? they would have to be in the position to sniff packets. thus on the same lan connected via a hub (or ARP flooded switch), on a router (most ppl dont have access to them), etc. basically its very difficult to be in the position to mess with players.

How about college dorm networks? One person can typically packet sniff their whole floor. How about cable broadband? Usually a whole neighborhood can happily packet sniff each other. You can't just push your security responsibilities onto the ISPs... they've historically set their networks up to allow this sort of thing.

quote:

sure i could IP spoof and send packets that i pretend originate from some other player (assuming somehow i was psychic and knew the IPORT that the other player was using) since most mulitplayer games i know of never give out client ips. only the server knows them, and other clients dont need to.

Voice comm, anyone? Client to client text messaging to save server bandwidth? IP exchange is too big a savings in other areas, it's often worth spending a few more CPU cycles per byte to cut bandwidth costs.

quote:

want to help stop that? use a public key system. this means two keys: private and public. the private key is linked to the cd key or installation media (ie cd serial) so its unique per player. maybe even have the player sign up to get a private public key pair. now each server has there own private and public keys.

*crazy homebrew key exhange algorithm deleted.*

Or, you could just use a Diffie Helman key exchange to exhange private keys and then use a private key encryption method. Much more secure and much lower CPU usage.

quote:

do some research into public key encryption and rsa. its not the fastest algo, but its pretty secure for what you want. ssh uses similar methods. you may wish to do some research on that as well since ssh allows secure communication between a server and client using TCP. the system does not trust either the server nor the client nor the pcs in between. so its designed for what you want.

RSA's great, but only for key exchange. It's a much bigger CPU hit than encryption needs to be once a connection is up and running.

quote:

also when i said the hacker would have the keys already since they would be at the client pc. i meant that most ppl would modify their clients so they could cheat instead of trying to mess up other players. since its pretty diffiuclt (and only a select few) can sniff packets in which they would change to mess up players. the hacker would gain no advantage nor even see the results. on the other hand players could easily goto sites to download cheats that modify how their client works so they could play better.

Player spoofing has been a problem since the early days of MUDs. I can think of numerous people who ere banned for spoofing messages or forcing other players to perform certain actions. People do it and it pisses victimized players off, it's a problem that any serious Online RPG programmer has to worry about. Come on, you know there are grief players out there. Their goal is not to cheat to improve their character, it's to ruin the game for everyone else.

[edited by - cheesegrater on July 29, 2002 11:07:17 AM]

##### Share on other sites
Well, what CheeseGrater said, and to stop those pesky script kiddies. Most "hackers" out there don''t know how to hack.. all they do is use third party software to do their work. I am working on stopping that, and making the job annoying for the real hackers.

I''m also going to be using well organized coding server side as my main measure. But I''m never satisfied with just one form of prevention.

Anyways, just to get back on track; I''ve been working on creating a CBC algorythm which can be MMX-optimized - but so far with no prevail. Is there anyone out there that thinks they have an answer?

##### Share on other sites
first off sniffing on a cable connection is somewhat tough since the modem should filter packets. secondly, client to client text messaging is not done via the clients ips. the server must moderate who can send messages to who. at the very least HL definatly dont use client to client messaging. since adminmod can filter fowl language (ie change what ppl say). furthermore most games i know of send all chat text through the server.

IM systems also send all data through a central server. apparently you never looked into how they work. at least AIM does this, pretty sure icq and the rest do as well (never used so i wont comment on them). true voice messaging is a direct connection, but this is when you use aim. voice messaging in HL is done via the server. its MUCH more bandwidth efficent to mix voice messages server side and send the single result, then send all idividual messages. furthermore if the central server was not the clearing house, anyone could talk to anyone. TCP definatly is not being used, if so clients would have trouble sending voice messages since they cant connect to my pc due to a firewall. through UDP it would not work since the packets are not routed through the NAT properly since the NAT cant know where to send packets for xyz when i never sent xyz any packets. again HL goes through the server. i know because mulitple pcs behind a firewall going through a single NATes IP address can communicate fine via HL.

so i guess your voice com software would have the lowly modem user send out his voice messages to all ppl participating in the chat instead of having the high bandwidth server handling this? i guess its also up to the client to be able to recieve from multiple parties and have the bandwidth to recieve all the voice data. realize this is a stupid design. anymore then 2 ppl in a voice chat means it will be more efficent to route everything through a higher bandwidth server then doing a peer to peer connections for the participating clients. so concurrent voice streams are mixed server side then sent as a single voice stream. sure much more cpu usage on the server end, but we want to save bandwidth.

sure you could directly use ips and message that way, but you need to be aware that many firewalls will disallow that. NATs make it troublesome and would disallow two ppl behind NATs to communicate at all.

yes my homebrewn key exchange is bad, and rsa can be slow. this is why i insisit on reserach on his part. i know he wants speed and security, but its diffiuclt for anyone to judge the compromises needed to be made. he needs to make the descicions since he best knows how connections work.

also Cheesegrater, i am merely giving an example of one method of exchange. sure its homebrewn and computential expensive. its merely another way of doing things. he could use a simple encryption system with a single key after the exchange, but any encryption system worth its bits will be somewhat computential expensive. there are some fast ones out there, and he shoudl go through them to decide what is fast and secure enough.

i never have witnessed nor seen player spoofing. i dont play muds, and this may be why i never seen it. i think you have to worry more about the client app being tampered with then the clients packets being tampered with. being that he is using UDP, i assume its a fast action game in which it would be quite diffiuclt to spoof packets. you see unless the hacker sniffing the packets can figure out the gamestae, it will be quite diffiuclt to send correct commands that the server will accept. with MUDs its just a matter of sending a text string command. with an action game you need to know the current player status and be able to block packets from the player otherwise the server will recieve multiple packets with the same id/timestamp. thus would randomly (depending on which gets recieved first) reject packets from the hacker or player. this could cause some problems. the hacker could increment the id, but no matter what there will be duplicate packets. MUDs and action oriented games are very different beasts.

hello2k1, unfortunatly as i said before, most encryption schemes can not be mmx optimized due to how they work. you cant very will work on the next 32bits if the previous 32bits are required for the encryption. i HIGHLY suggest using a standard encryption algorithm. using anything homebrewn and optimized for mmx can cause it to be weak to a slew of attacks. most encryption schemes are slow because they want to try and prevent brute force atacks with a large key space AND an algo that requires many cycles to go through the key space in its most optimized form. i mean whats the use of 32 billion keys if i can calculate a billion keys a second?