Curious… but,
Is it necessary to use secure sockets in a multiplayer game?
If not, when is it appropriate to use a secure socket in game development?
No, just use TCP/UDP. If you want something secure you can encrypt it.
The short answer is “maybe”. However at the start there is no need. Get it all working. Adding SSL later is pretty easy but you must use TCP. Well i think UPD is oversold in most cases for games and its “faster” claim is mostly myth. So you should be using TCP anyway.
Adding it properly is easy, but doing the certificates properly is a pain and typically expensive. Also recent breaches have shown that Cert issuers are not really all that secure. But for a game these issues don’t really matter.
Also if all you want is to add a layer to reverse engineering the protocol, then adding it yourself to the stream is not so hard. Remember in both cases the protocol reverse engineer always has access to the plain text (unencrypted stream) and the key. So it will only slow them down somewhat.
Note that adding encryption is not authentication. SSL gives both Authentication and encryption with full Certs.
I think it’s good practice to have this implemented early on (it’s not even that difficult). You want to prevent packet injection, sniffing, etc.
The proper approach would be to use a strong algorithm like RSA to encrypt your authentication, then use some fast RNG to encrypt regular packet id’s (or if you really wanna go overboard you could encrypt multiple parts of a packet). You can use WELL512, ISAAC, etc. I’m not sure about their relative speeds…
If you going to do it yourself, you use a proper set of off the self encryption methods with off the self modes, aka AES or some such. Using a random number generator that is not a stream cipher will not give you anything. Java has a full set of stuff including public key and symmetric key stuff as well as a MACs and co.
If you don’t know what any of that means… don’t do security your self… or get a good book or three.
They are stream ciphers… (ISAAC, WELL512) furthermore, Java encryption methods are slow, I don’t think there is a faster RNG than ISAAC. for my game, I use ISAAC and RSA (for authentication only)
Java encryption uses jni to native c libs across the board when i used it.
Ehmmm. And?
I can pretty much guarantee using a Java implementation of ISAAC is faster (and in worst case just as fast, but I doubt it).
Out of curiosity do you encrypt the whole packet payload and all, or just the opcode/id?
My point was they are the same speed as C or so close to it in my tests and implementations, and you can plug any method you want in ISAAC or whatever. Don’t know why you came to the “java slow” conclusion.
Not sure if that last question was directed at me. But the whole payload and have a mac of course. But i don’t follow the opcode/id thing?
BTW they i said use proper to the original poster, so they don’t just use any old code or even worse random number generator (MS did not diverse a mention there…), while java does have a set built in. Speed for a game is also quite moot since its small potatoes compared to the game itself.
How do you know what type of packet you are receiving? Don’t you use an id to identify different types of packets, like first byte you send is the id, then after that is payload (or maybe size if it’s not a fixed sized packet, and THEN payload). My point was you just need to encrypt that, not the payload
Well my current stuff just encrypts the stream with intermittent macs… i check these ids after decryption. I am using TCP. Depending what the goal is you must encrypt the payload or at least include it in the mac… It would be very easy to work out the id if the payload is plain text. So what was the point? also if a mac is not checked properly then the payload can be changed and then folks can cheat even with an encrypted id. Cheat prevention is my main goal here.
General rule, encrypt all you can, mac everything that is part of the “message”. You can’t encrypt the destination IP for IPSec of course, but it can be part of the mac. Its the “to” field of a email and hence is part of the message.
you can’t guess the content of a packet. how would you know if it was plaintext? how would you know if it’s actually just a bunch of longs? or an int and a long? without knowing what the packet is trying to communicate, you can’t effectively cheat.
even if you were still worried that someone would guess that the packet is plaintext, you could encrypt certain packets and leave other packets be.
anyways, it shouldn’t be possible to ‘cheat’ anyways, since the client should only send commands to the server
Longs int etc will and do have a very distinct pattern. It would be trivial to determine protocol details if payloads are not encrypted. Even ECB makes this sort of thing easy. I am beginning to think you have not done much cryptography?
Quake3 aim bots used packet injection to cheat. The “impossible” to cheat idea works well in labs…
That’s why you mix up methods of sending data.
i.e. use little endian and big endian integers in the same packet, among other methods of making the data without patterns (i use at least 6 different methods of sending an integer)
it’s not required to encrypt everything, just a waste
Seriously you have no idea what you are talking about. Encryption is also very cheap. You can encrypt it far faster than you can send it. The catch is you must mac it as well. Even different packet lengths makes working some details very easy. Looking for a type of message in a p2p game like most RTSes can then give you info on what others are doing like… One guy just spent a lot of cash, or selected a lot of units. Of course encryption does not completely avoid this either. But it can make it harder… These sort of attacks have been done, they are not just theory.
Also it is more complicated to only encrypt parts of things. It is far easier to encrypt everything or nothing, not some random mix of things. We are not running 486 anymore.
FWIW I have done some crypto work professionally. SSL encrypts everything it can for a reason.
OK since you don’t seem to believe that my method is secure (i don’t think you understand what i’m trying to say) how about I give you a couple of thousand of the same packet, generated from my game (i’ll just print them out). according to you, you should be able to tell which parts of it are an integer, byte, short, etc or whatever the payload may consist of?
challenge accepted?
i’ll give you any information that can be found on the client if you require it, (for example my Buffer class that handles the decrypting)
heck, i’ll even strip out half the encryption methods I use in the Buffer class to narrow it down and make it easier
Dude read some basic intros into cryptography… hell even just browse some posts on sci.crypt. The famous “my method is invincible, try and crack it–see no one can! There is your proof!”. We have better things to do that crack something we know is easy or just plain stupid. You don’t have a proof of security by others not caring about your crap protocol.
There is a lot of work on this, and much if not all of it is free to download (papers etc).
I don’t think what you have is insecure, i know it is. Just save yourself the time and use double ROT13.
Delt0r – out.
I knew you didn’t understand what I was saying… I use same concept as ROT13
some code:
public int get() {
return buffer[readPos++] & 0xFF;
}
public int getNByte() {
return -buffer[readPos++] & 0xFF;
}
public int getNUByte() {
return 127 - buffer[readPos++] & 0xFF;
}
public int getUUByte() {
return 128 + buffer[readPos++];
}
i know that you will never be able to decrypt my packets, and you know it too, which is why you refuse the challenge.
Dude, ROT13 is so obsolete, you should totally be using ROT26 :