Forum :: Programming :: Proper Packet Protocol

 

I'm not a coder, and i browsed this a little, but this would pretty much make someone need an encryption/password to force packet changes?

o.o?

---
Hail Satan!

Suave posted: (1st Oct 2012, 11:19 am)

Sausage is right, though. It's stored on someone else's computer. Although, securing more with "encryption" is still a good idea as it would just make them take longer.

Not only will it take them longer but certain people will not have the ability to crack the "encryption".

@omen, No, they wouldn't be able to make packet changes with this system because in editing of bytes of the encoded packets will deform the data because all the bytes are dependant of each other. This will mess up the sequence byte and if that sequence byte doesn't match what the server thinks it should be, the client will be disconnected.

---
Andrewbob - I would be on the fucking copter of rofls

Programmer, Web Developer, and Graphics Designer

I understand the point. Decrease the percentage of people that can decrypt it.

As someone who's actually done exactly what you're trying to stop people from doing, you're probably better off using actual encryption. It would be easier to obscure the code that generates the key as it is to think about all the stupid byte flip-flop garbage you could to do try and make your packets look weird. Actual encryption could be made actually secure (as in, not just childish "Lol you can't read me I'm backwards", but requiring millenia for a third party to decrypt packets even given the algorithms), plus make them actually resistant to showing any patterns from the input compared to the output (1 1 1 1 1 encodes to 2 3 4 5 6 with Plasmastar's method, obviously giving your s00p3r s3cr3t 3nc12ypt0rz away) due to guaranteed noise distribution (trying to work out what input would give "2 3 4 5 6" in a real cypher should be a mathematically hard problem, even given the key, I think(?)).

Still, at that point, people will just hook directly in to your program and start injecting false packets directly, getting your program to do the encrypting for them.

Edit: Almost forgot the best part. Doing certificate authentication would make your client unable to connect to any "uncertified" servers without hard modification (though if every server can share the same login credentials, that alone is probably enough to verify the server is valid), protecting you from another kind of MITM attack, as well as an unedited client wouldn't be able to connect to any private servers (though that could be achieved by hard-coding making server addresses unavailable for editing, that's much easier to work around, simply by fudging the DNS (if you rely on that) or re-routing the connection / hacking the connect() call etc. if you store the IP directly (which will be a huge bitch if you want to move servers)).

Don't be a Vultard.

Sausage posted: (1st Oct 2012, 07:37 pm)

As someone who's actually done exactly what you're trying to stop people from doing, you're probably better off using actual encryption. It would be easier to obscure the code that generates the key as it is to think about all the stupid byte flip-flop garbage you could to do try and make your packets look weird. Actual encryption could be made actually secure (as in, not just childish "Lol you can't read me I'm backwards", but requiring millenia for a third party to decrypt packets even given the algorithms), plus make them actually resistant to showing any patterns from the input compared to the output (1 1 1 1 1 encodes to 2 3 4 5 6 with Plasmastar's method, obviously giving your s00p3r s3cr3t 3nc12ypt0rz away) due to guaranteed noise distribution (trying to work out what input would give "2 3 4 5 6" in a real cypher should be a mathematically hard problem, even given the key, I think(?)).

Still, at that point, people will just hook directly in to your program and start injecting false packets directly, getting your program to do the encrypting for them.

Edit: Almost forgot the best part. Doing certificate authentication would make your client unable to connect to any "uncertified" servers without hard modification (though if every server can share the same login credentials, that alone is probably enough to verify the server is valid), protecting you from another kind of MITM attack, as well as an unedited client wouldn't be able to connect to any private servers (though that could be achieved by hard-coding making server addresses unavailable for editing, that's much easier to work around, simply by fudging the DNS (if you rely on that) or re-routing the connection / hacking the connect() call etc. if you store the IP directly (which will be a huge bitch if you want to move servers)).

Don't be a Vultard.

your to smart man love seein these topics you reply to!

insomniac posted: (1st Oct 2012, 08:13 pm)

Sausage posted: (1st Oct 2012, 07:37 pm)

As someone who's actually done exactly what you're trying to stop people from doing, you're probably better off using actual encryption. It would be easier to obscure the code that generates the key as it is to think about all the stupid byte flip-flop garbage you could to do try and make your packets look weird. Actual encryption could be made actually secure (as in, not just childish "Lol you can't read me I'm backwards", but requiring millenia for a third party to decrypt packets even given the algorithms), plus make them actually resistant to showing any patterns from the input compared to the output (1 1 1 1 1 encodes to 2 3 4 5 6 with Plasmastar's method, obviously giving your s00p3r s3cr3t 3nc12ypt0rz away) due to guaranteed noise distribution (trying to work out what input would give "2 3 4 5 6" in a real cypher should be a mathematically hard problem, even given the key, I think(?)).

Still, at that point, people will just hook directly in to your program and start injecting false packets directly, getting your program to do the encrypting for them.

Edit: Almost forgot the best part. Doing certificate authentication would make your client unable to connect to any "uncertified" servers without hard modification (though if every server can share the same login credentials, that alone is probably enough to verify the server is valid), protecting you from another kind of MITM attack, as well as an unedited client wouldn't be able to connect to any private servers (though that could be achieved by hard-coding making server addresses unavailable for editing, that's much easier to work around, simply by fudging the DNS (if you rely on that) or re-routing the connection / hacking the connect() call etc. if you store the IP directly (which will be a huge bitch if you want to move servers)).

Don't be a Vultard.

your to smart man love seein these topics you reply to!

Same :) I was reading this topic and it made me feel like i should be back in primary school learning colours and shoving glue up my nose.

He knows his stuff. If what he said made you question your intelligence then I feel bad for you. 

Regardless, Sausage is right. MITM is inevitable.

Just to clarify, when I say MITM I'm referring to knowledgeable, unknown third parties that have access to the network between your server and your users snooping for passwords (or chat logs, more likely), or trying to emulate/proxy your server to harvest them, which are the attacks encryption is supposed to prevent. Of course, the chance of your game being targeted in such a way is extremely unlikely, unless you happen to wind up with some government's person of interest using it to communicate, but I'm sure plenty of ISPs will happily log any conversations it can get its hands on, though. I'd rather be safe than spied on.

End users who want to try mess with your game, though, will of course, inevitably find a way to manipulate packets if they try hard enough, but at least the encryption is serving its actual purpose, and you didn't just put it there to be obscure and difficult.

Yeah, I thought about certification as well. It seems like an option but id have to look more into it. I do know that MITM is inevitable but I at least want them to need to put up a fight. 

 

---
Andrewbob - I would be on the fucking copter of rofls

Programmer, Web Developer, and Graphics Designer

Again, MITM does not refer to end users hacking your program... Encryption does the job of preventing MITM (by it's actual meaning) except in the case where they control the initial communication (which would be the HTTPS handshake when they download your client if you use HTTPS to serve and verify your website/client, if the visitor doesn't notice the name on the certificate isn't what it should be).

Ok I read up on some encryption articles. These are my thoughts. asymmetric envryption looks better then symmetric. Im thinking of using a public key to decrypt which will be sent to the receiver and use a private key to encrypt. Each packet will contain the authentication  signing that is encrypted using the private key and if the decrypted sign is nonsensical using the public key, it is not authentic.

---
Andrewbob - I would be on the fucking copter of rofls

Programmer, Web Developer, and Graphics Designer

Two keys are better than one! xD

But if they were really trying wouldn't it still be one key to crack?...

---
Hail Satan!

Omen posted: (1st Oct 2012, 11:47 pm)

Two keys are better than one! xD

But if they were really trying wouldn't it still be one key to crack?...

It's called a Public key, and a Secret key. I get confused as to which is called which because...well, you'd technically have access to both, if you got one. But isn't the one that both of them knows called the Secret key...and the one they both tell each other, the Public key?

---
Wish upon a star!

Plasmastar posted: (1st Oct 2012, 11:51 pm)

Omen posted: (1st Oct 2012, 11:47 pm)

Two keys are better than one! xD

But if they were really trying wouldn't it still be one key to crack?...

It's called a Public key, and a Secret key. I get confused as to which is called which because...well, you'd technically have access to both, if you got one. But isn't the one that both of them knows called the Secret key...and the one they both tell each other, the Public key?

No. The public key is used to decrypt. Both receivers have a public and a private key. They both know each others public keys. Meaning, they can only decrypt each others messages. They encrypt it using their own private key, then the other decrypts it using the public key they were given. Each key pair is randomly generated for per-session use.

Think of it in eoserv terms as this:

Client:

EMultiE: Value is generated and is only known by the client and is used to encrypt its own messages

EMultiD: Value is generated by the client and is used by the server to decrypt the clients messages

 

Server:

EMultiE: Generated and is only known by the server and is used to encrypt its own messages

EMultiD: Generated by the server and is used by the client to decrypt the servers messages

 

What the client knows:

The both the clients keys

The servers EMultiD

 

What the server knows:

The both the servers keys

The clients EMultiD

 

The difference is that the server doesn't generate the keys for the client to use and instead both of them generate a key to decrypt the messages and exchange it with each other.

---
Andrewbob - I would be on the fucking copter of rofls

Programmer, Web Developer, and Graphics Designer

I think I just dropped an IQ point... Thanks for nonsense.

If you encrypt a string with a key, that key HAS to be known to decrypt it. Both sides know it, or there wouldn't be any real communication...

---
Wish upon a star!