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***

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.

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

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.

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.

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.