   Another Security Thread
  Hello,I am trying to implement a way to encrypt my packets.Could you please tell me if the AES method is fast and short please ?Is Blowfish better, faster ?After that, I would like to know how to generate a random AES encryption key in C++, because I would like the server sends a random key to the player once that one has just connected.Maybe I'm wrong, but can the AES key have any string length ?If it's too hard to generate a random key, is it safe to store a unique key somewhere in the program ? I'm afraid that we can find it by disassembling if I store it in ASCII.Thanks.[Edited by - Linaxys on April 20, 2009 12:35:12 PM]
  First things first: why are you trying to encrypt your traffic? 90% of the time when people ask how, it's because they're doing something that is ultimately a waste of their time, since they're often failing to consider more fragile and accessible breach points.   ;  Using AES like that will not give you any security. Because it doesn't matter how you will store key in your application (ASCII or binary). If you will store key at all then anybody can retrieve key and decrypt your packets.AES is very fast. On modern computer it can encrypt about 70MB/s and more.AES key is usually generated as hash from some string (for example entered password). Or if key needs to be random, then its simply randomly generated. No special restrictions (except good random).   ;Quote:Could you please tell me if the AES method is fast and short please ?Is Blowfish better, faster ?The wikipedia page on Blowfish has some notes on speed compared to AES.Quote:Maybe I'm wrong, but can the AES key have any string length ?My understanding is that AES is a number of ciphers which each work on a fixed key length.Quote:After that, I would like to know how to generate a random AES encryption key in C++, because I would like the server sends a random key to the player once that one has just connected.How is the key exchange protected?Quote:If it's too hard to generate a random key, is it safe to store a unique key somewhere in the program ?No, that isn't a good idea.Quote:I am trying to implement a way to encrypt my packets.What kind of attacks are you trying to protect against?   ;  Well guys, alright, I don't really know what to do just because I don't know really a lot of things about multiplayer safety and stuff...Quote:Original post by rip-offQuote:I am trying to implement a way to encrypt my packets.What kind of attacks are you trying to protect against?I am making a 3D Chat, using ENet, and in other programs, when I use WinsockPacketEditor, I see some weird stuff like \...$!!~~...!....*...., and no string at all.I am really afraid of people that could cheat by editing their packets so easily, like sending a fake name, speedhacking...Then I would like to know the following :- How can I make sure that the packet I send is not too big or too long to be received ?- How can I tell the server to check if the packet is the same as it was made by the player ? (some kind of CRC32 check or I don't know, sent by the player somewhere in the packet).- Or everything in one question : How can I check if the connected client is real and not a simple funny guy using Telnet or a simple VB App to connect via UDP to my server ?Thanks for your help, I'm really getting confused and, I have a very big paranoia.   ;Quote:Original post by LinaxysCould you please tell me if the AES method is fast and short please ?Is Blowfish better, faster ?Whenever one encounters a question of "fast(er)", this is how to approach it.There are many factors which affect "fast", and many of them aren't even code related. But writing a simple, repeatable benchmark, then letting it run real world examples is a very good start at getting a feel of how something behaves.   ;Quote:sending a fake name, speedhacking...By "sending a fake name", do you mean taking someone else's account? Having some kind of password system should stop this. You don't need encryption for passwords, a challenge response protocol where the server sends a nonce to the client, and the client responds with the hash of the password and nonce should work.Speedhacking should be preventable by making the server authoritative and correctly programming it. It cannot be dealt with at the packet level.Quote:Then I would like to know the following :- How can I make sure that the packet I send is not too big or too long to be received ?You could discover the path MTU size. Enet might handle this for you, or might allow you to specify your own upper limit over which it might automagically fragment packets.Quote:- How can I tell the server to check if the packet is the same as it was made by the player ? (some kind of CRC32 check or I don't know, sent by the player somewhere in the packet).Yes, a CRC or hash will give you a check. This will only protect against accidental corruption, not malicious packet editing. Remember, UDP all ready does a minimal 16 bit checksum, which gives you limited protection against corruption anyway.Quote:- Or everything in one question : How can I check if the connected client is real and not a simple funny guy using Telnet or a simple VB App to connect via UDP to my server ?You can't.   ;  Hmmm, well, ok, I will try to use the nonce method...I've never used a nonce, should I use it in every packets that need to be replied ?I mean, this ://// Server Side//myPacket sendPck;thisClientNonce = rand() % 100;sendPck.WriteByte(thisClientNonce);sendPck.WriteString("Question?");sendPacket(Client, &sendPck);//// Client Side//myPacket pck;nonce = pck.ReadByte();stringc str = pck.ReadString();replyPacket pck;pck.WriteByte(nonce);pck.WriteString("Answer!");//// Server side//myPacket rcvPck;getNonce = rcvPck.ReadByte();if (thisClientNonce == getNonce) {// Good packet !} else {// Bad answer, just ignore it.}Well, I'm going to work more on my network part, I have realized that encryptiong should not be really necessary anyway, because it could be stupid that if someone break it, the game will look like having no encryption...What would be a good solution to prevent someone flooding the server ?I've heard something like storing a value like "getTime() + 20", if the user tries to send a packet in less than 20 ms after the last one, then it's ignored,...How many milliseconds should I check ? 20 ms would be sufficient ?Thanks you guys !   ;Quote:I've never used a nonce, should I use it in every packets that need to be replied ?No.The purpose of the nonce is to prevent replay attacks on the password. The nonce is supposed to make sure that every time you login to the server you are sending a different value, but it can still be checked for validity.There are a few different things happening in what I described. Here I will build up the protocol, giving reasons why each element is introduced.Let us consider first the simplest protocol: send the password in plaintext.Vulnerabilities: pretty obvious, the attacker can see the password and login as the user with very little effort.Slight improvement: send the hash of the password.Vulnerabilities: The attacker can no longer directly login as the client. They can however, store the packet the client sends and replay it to the server. So even though the attacker doesn't know the password, they still can get access.Better again: send the hash of a password and a nonce. That is, hash(password concatenated with nonce).Vulnerabilities: Very low chance that if an attacker records all the packets sent to a client they will ever get a chance to use a replay attack, as the server should be generating different nonces each time. Even if they do, this is a once-off opportunity to login, once logged out they must go through the same waiting process again.The nonce should therefore have a wide range, not just a single byte with a value between 0 and 99. The idea is to ensure the chances of the server sending the same nonce to a given client is quite low over the lifetime of a password.   ;  You may want to read my article on game authentication for some background information. You can find it in Game Programming Gems 7.However, it sounds to me as if you're just trying to protect the wrong thing. The data in flight is almost never altered. The data is typically altered in the client, by injecting a new socket DLL, or by editing client memory directly. Thus, no matter how you encrypt data, the client should be assumed to be capable of cheating.Thus, on your server, you should treat all data that comes in as possibly bad data, and you should code appropriately. If someone tries to bend the rules by sending a packet that changes the game state in a disallowed way (moving too fast, or whatever), either disconnect them, or just apply the rules and tell them what the real outcome of their action was, so they can correct their display. (Sometimes, those packets can be the result of different hardware, network delays, etc, and not cheating, so immediate disconnect is seldom the best strategy)In short, it sounds like you don't need help with encryption, it sounds like you need help with designing enforcible game rules.