Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Secure Sockets  (Read 2146 times)
0 Members and 1 Guest are viewing this topic.
Offline tw0v

Junior Devvie


Medals: 1
Projects: 1



« Posted 2011-12-28 13:08:20 »

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?

Programming for better games.
Offline roland
« Reply #1 - Posted 2011-12-28 13:12:07 »

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.

Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #2 - Posted 2011-12-28 13:17:18 »

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.

I have no special talents. I am only passionately curious.--Albert Einstein
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #3 - Posted 2011-12-28 13:18:47 »

Note that adding encryption is *not* authentication. SSL gives both Authentication and encryption with full Certs.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline counterp

Senior Devvie


Medals: 11



« Reply #4 - Posted 2011-12-28 15:10:26 »

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...
Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #5 - Posted 2011-12-28 16:43:52 »

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.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline counterp

Senior Devvie


Medals: 11



« Reply #6 - Posted 2011-12-28 18:38:55 »

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)
Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #7 - Posted 2011-12-28 18:50:55 »

Java encryption uses jni to native c libs across the board when i used it.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline counterp

Senior Devvie


Medals: 11



« Reply #8 - Posted 2011-12-28 19:37:12 »

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?
Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #9 - Posted 2011-12-28 20:09:37 »

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.

I have no special talents. I am only passionately curious.--Albert Einstein
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline counterp

Senior Devvie


Medals: 11



« Reply #10 - Posted 2011-12-28 20:40:21 »

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
Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #11 - Posted 2011-12-28 20:52:20 »

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. 

I have no special talents. I am only passionately curious.--Albert Einstein
Offline counterp

Senior Devvie


Medals: 11



« Reply #12 - Posted 2011-12-28 23:05:54 »

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
Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #13 - Posted 2011-12-28 23:25:54 »

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

I have no special talents. I am only passionately curious.--Albert Einstein
Offline counterp

Senior Devvie


Medals: 11



« Reply #14 - Posted 2011-12-29 10:23:14 »

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
Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #15 - Posted 2011-12-29 10:45:38 »

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.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline counterp

Senior Devvie


Medals: 11



« Reply #16 - Posted 2011-12-29 11:07:31 »

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
Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #17 - Posted 2011-12-29 11:36:27 »

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 have no special talents. I am only passionately curious.--Albert Einstein
Offline counterp

Senior Devvie


Medals: 11



« Reply #18 - Posted 2011-12-29 12:41:35 »

I knew you didn't understand what I was saying... I use same concept as ROT13

some code:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
   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.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #19 - Posted 2011-12-29 13:54:02 »

Dude, ROT13 is so obsolete, you should totally be using ROT26  Roll Eyes
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (30 views)
2014-12-15 09:26:44

Mr.CodeIt (23 views)
2014-12-14 19:50:38

BurntPizza (50 views)
2014-12-09 22:41:13

BurntPizza (84 views)
2014-12-08 04:46:31

JscottyBieshaar (45 views)
2014-12-05 12:39:02

SHC (59 views)
2014-12-03 16:27:13

CopyableCougar4 (57 views)
2014-11-29 21:32:03

toopeicgaming1999 (123 views)
2014-11-26 15:22:04

toopeicgaming1999 (114 views)
2014-11-26 15:20:36

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!