1 (edited by Dune 2009-12-22 15:16:57)

Topic: [SUGGESTION] RSA encrypted authentifications for 0.6

Hello,

Here is a suggestion for the 0.6 version of teeworlds, and perhaps a solution to cheat, including bots.

First, I must explain you how the RSA encryption works :
There are two keys, a public one, and a linked private one.

Using those keys and the Fermat's little Theorem :
Any message A you encrypt with the private key gives you an other message B.
If you encrypt this message B with the public key, then you find the message A.

One example :
Act 1
Romeo and Juliette wanna speak together. Romeo send mails to Juliette, but Juliette wants to be sure that the mail really comes from Romeo.
Then, Romeo choose one private key X, deduce the public key Y and broadcast Y.

Act 2
1.Romeo wants to send to Juliette : "I love you".
2.Romeo crypt the message with X and gets "t sDfé P3m".
3.Romeo send to Juliette "t sDfé P3m".
4.Juliette crypt "t sDfé P3m" with Y and gets "I love you".

The End !

Actually, Romeo is the client and Juliette the server.
The server wants to verify that the client who tries to authenificate isn't a bot.

The server send a random number A to the client.


RSA



The server knows the client isn't a cheater.
You can easily deduce Y when you know X (at its creating), and RSA encryption is very quick (just a modulo, a %) , and absolutely secure (used with blues cards).

Teeworlds part
As I suggest, Teeworlds devs will choose a private key X. They will deduce the public key Y and will broadcast the sources of the server, including that public key Y.
They will release too the sources of the client, but deleting the encryption function. Then, if you try to connect to a server with a hand-compiled client, you will be considered as "non-pure".

Then, here you choose.

  • You can choose to allow only validated clients, that could be quickly validated by sending the final sources to a moderator or by releasing them on a topic and asking. That means that devs will need to include a command in the server to allow non-validated clients for lan testing

  • You can choose to broadcast in the game (while pressing tab, or behind the name) who got a non-validated client

  • You can choose to do not validate any client, just to broadcast who got a pure client

And of course :

  • You can choose to throw my idea in the oblivion of some kind of lost dungeon and forget it for ever

Awaiting feedback,
Dunedune.

Not Luck, Just Magic.

2

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

Imo this doesnt prevent all cheating because not all forms of cheating are a result of modified source, the second thing is I am not sure it is worth implementing this, since it has been said a lot of times that fighting cheaters is not worth it, I would rather see the devs developing the game for the good of us all, than having to fight cheaters. Seriously, who cares, play on moderated servers, thats all. But if you have the potential to code this just go for it, I'm not saying this is not needed, I just want to say that imho its an overkill for a not-that big problem.

We will meet again when the flowers spread their glorious scent of victory and the birds sing us the melody of justice...

3 (edited by clarus 2009-12-22 14:29:14)

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

They will release too the sources of the client, but deleting the encryption function.

So, to summarize, your solution is to make TeeWorlds not open-source. I have a simpler idea : just don't release the source.
But as already said so many times, TeeWorlds must stay open-source.

4 (edited by buffer[] 2009-12-22 15:00:36)

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

torch wrote:

Imo this doesnt prevent all cheating because not all forms of cheating are a result of modified source

Yep there are color bots for example.

Moreover, open-sources means you release all sources,
and people may be able to cimpile them and got the official client.
In your case, that's means you'll got fake sources, cause the encryption function was deleted,
and you can't got the official client by compiling sources.
This would be the end of modded client...

Btw, people who have their server can just modify sources, and don't check encryption (so people even if they got modded client could conntec, and be shown as pure clients).

|ZPote| buffer[]'s posterous

5

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

torch wrote:

Imo this doesnt prevent all cheating because not all forms of cheating are a result of modified source.

Even if this doesn't prevent all cheating this prevent at least from bots, which is the most problematic cheat. It also prevents from zooming out and auto-join.

buffer wrote:

Moreover, open-sources means you release all sources,
and people may be able to cimpile them and got the official client.
In your case, that's means you'll got fake sources, cause the encryption function was deleted,
and you can't got the official client by compiling sources.

Read it well. It will just mark the client as non-pure... you still can compile the sources and get a full-working client, there will just be broadcast that this is not the official client.

Btw, people who have their server can just modify sources, and don't check encryption (so people even if they got modded client could conntec, and be shown as pure clients).

Of course, if servers want to allow bots, they can (as I said there should be a command, mostly for lan client testing).

I don't think that making a private key would destroy the nature open-source of teeworlds. I don't know the exact definition, so perhaps it's true you couldn't call it open-source, but I just give a way to mark pure clients... nothing more.

Not Luck, Just Magic.

6

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

Dune wrote:
buffer wrote:

Moreover, open-sources means you release all sources,
and people may be able to cimpile them and got the official client.
In your case, that's means you'll got fake sources, cause the encryption function was deleted,
and you can't got the official client by compiling sources.

Read it well. It will just mark the client as non-pure... you still can compile the sources and get a full-working client, there will just be broadcast that this is not the official client.

So as I said, you won't get the official client, which is marked pure -_-

|ZPote| buffer[]'s posterous

7

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

It will still be possible for a client to send the correct public key, just extract it from the "signed" binary and send that. All these ideas won't really stop anything, just make it a bit harder.

Languages shapes the way we think, or don't.

8

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

void wrote:

It will still be possible for a client to send the correct public key, just extract it from the "signed" binary and send that. All these ideas won't really stop anything, just make it a bit harder.

I don't undersand you... you're telling me that the client "just" have to extract (?) the original number... how ?

Not Luck, Just Magic.

9

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

The trusted client (the binary) contains the private key, which can be extracted by means of debugging and reverse-engineering.

We will meet again when the flowers spread their glorious scent of victory and the birds sing us the melody of justice...

10 (edited by Dune 2009-12-22 18:36:14)

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

Well, then don't put :

private_key = "4Z3GDFG54"; // Here is the private key !

I'm sure we can find ways to avoid that wink

Not Luck, Just Magic.

11

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

I'm sure you can't

Drowning dwarves lately

12 (edited by buffer[] 2009-12-22 19:12:42)

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

Dune wrote:

Well, then don't put :

private_key = "4Z3GDFG54"; // Here is the private key !

I'm sure we can find ways to avoid that wink

Sure you can find it anyway.
That's the use of reverse-engineering, use for crack for example.

|ZPote| buffer[]'s posterous

13

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

i totally aggree with torch´s first post  to much effort for a minor problem. First of all where do we have most cheaters? in Instagib ( Original a trainings mod for the new weapon screw you chi1 !!! for being a lazy ass ) and not vanilla. For me i have never seen a bot owning that hard in vanilla

The devs don´t care about mods except those mods which provide an advantage in vanilla ( some mod clients well there are other topics for this issue).

In the end the only solution for this issue is:
- Play on thrusted servers
- Play Vanilla or else don´t complain about bots

This is only about thrust between players, if your opponents can´t play fair then just don´t play with them. Last thing needed for this is an account system to verify that it is really you who is playing with that nick.

14

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

Another reason why your system won't stop botting is that some (aim)bots are not compiled directly into the client but .dll or similar files, that are included in the client while it is running, you only need the client binary. It is not that hard to code something like that if you have the sources of the client(even if encryption function is missing, it does not change anything for that) so you can just download the "pure" client and then still use the aimbot/whatever dll, and your client will be marked as pure, as it includes the encryption function.

I agree to the persons who have posted here before, that it is simply a huge effort for minor or none effectivity at all.

And maybe we should think about people who are using operating systems, for which the devs don't provide biniaries, but are able to compile tw for them selves. They would never be able to get a pure client and thus often be accused of cheating and so on.

I see you have put a lot oft thought into that system, but it just won't work for teeworlds while keeping the open source spirit, and this is something we should not give up!

15 (edited by Dune 2009-12-22 23:21:04)

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

i totally aggree with torch´s first post  to much effort for a minor problem. First of all where do we have most cheaters? in Instagib ( Original a trainings mod for the new weapon screw you chi1 !!! for being a lazy ass ) and not vanilla. For me i have never seen a bot owning that hard in vanilla
The devs don´t care about mods except those mods which provide an advantage in vanilla ( some mod clients well there are other topics for this issue).

An answer from a vanilla-man. There have been many discuss about that, and I think we shouldn't keep it closed, that is linked to all topics about making instagib official, and if or not devs should care about that and provide some stuff to avoid cheats on instagib.
I have my opinion and many argues, but I will try to do not deviate the way of this topic.

Marik16 wrote:

Last thing needed for this is an account system to verify that it is really you who is playing with that nick.

LordSkelethom wrote:

The main dev seems want to integrate an account system, like in the majority of online multiplayer games. understand that in the next teeworlds release you will have to register and then login before playing.



ghost91 wrote:

Another reason why your system won't stop botting is that some (aim)bots are not compiled directly into the client but .dll or similar files, that are included in the client while it is running, you only need the client binary. It is not that hard to code something like that if you have the sources of the client(even if encryption function is missing, it does not change anything for that) so you can just download the "pure" client and then still use the aimbot/whatever dll, and your client will be marked as pure, as it includes the encryption function.

Thanks, that is really info. I haven't thought at all about that... yeah unfortunately it will just make it harder.

ghost91 wrote:

I agree to the persons who have posted here before, that it is simply a huge effort for minor or none effectivity at all.

Really, if my post is so large, this is because I wanted you to understand well what RSA encryption does. Implementing it is easy, and very fast at execution. That is NOT a huge effort.

Captain AMN wrote:

I appreciate the effort Dune but i think i must agree with matricks here, who wrote that fighting cheaters is senseless in the long run.

I think it could be effective, but devs do not seem to care a lot about instagib, and chose to do not spend many time to that. I understand that, and it's why I try to afford some ideas, but I really think this fight isn't hopeless. And it does not concern only instagib, to see how magnet and matricks defined cheat clients.

Captain AMN wrote:

However though, i would like to see a server/client equipped with this and give it a try at least, maybe before a big tournament in teeworlds is hosted, so we can play atleast 1 tournament with the certainty that nobody cheats. But like said, this would be quite much work just for such a short timespan and it would be hacked anyway soon, if someone evil enough tries.

Thank you a lot, I will work on this when I will manage to compile (Windows 7, be damned !). I studied this encryption last year, and I can do all the mathematic parts. About the informatic one, I will perhaps need some help to see how bad I am in networks, but I think I will get it.
However I think hacking that will be long, hard and will require skills few people have, so I really don't think anybody will try to do this for a tournament. Nevertheless, I will encourage everybody to do this if he can.

BTW: I think it's very impolite to vote his topic down. It's well written, structured and illustrated. Give him an arrow up, it's awesome to see people trying to develop the game further.

Thanks.

To conclude, I agree with you that this won't stop for a long time cheating, and that it ai'nt a nice idea to include that in 0.60. I'm thankfull to everybody for this useful feedback.

Edit : Please do not close this topic, I will release some sources/binaries wink

Not Luck, Just Magic.

16

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

I really like the effort you seem to be putting into this, and there's nothing wrong with the encryption part except that your scheme trusts the client, which you cannot do. I don't know why people are modding you down, certainly not deserved.

Languages shapes the way we think, or don't.

17

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

Don't release binaries, it would mean losing the edge.

Program it, and the day there is a tournament, provide the server to the admin and let only registered players download the client. Change the key every day or every few games (that means restarting the server too).

After a few days the key might be reverse engineered so it would be too late to be trusted (or I would have done this for tournaments before), the only thing left is to buy time using steganography and making it harder to find the new encryption key. That's what MMO developers spend their life doing instead of implementing new features.

As we have said many times before, this is an endless fight with no hope of real victory. As long as people control software on their PCs (and that's something we all hope for anyway). You might as well try to remove cheaters from the Internet smile.

But the positive side of that particular method is that it actually works for some time, but it is solely based on the trust you can put in the key.

As ghost said, it won't provide ad-hoc cheats such as aimbots that run in DLLs (for that you need to run a tool on TW's client code for each trusted client release that changes the hooks/memory addresses the DLLs are looking for).

18

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

Magnet wrote:

Also, void, it's not as easy as reading the key in the packets using a man in the middle attack if he's using RSA, which is also used by SSH for instance and does a handshake less susceptible to repeat attacks. But it's as easy as reading the RSA key in the client code, unless it's mangled/steganographied and until it's found. Hence the need to change not only keys, but their integration in the client source code (and server source code if you don't trust the admins either).

It's easy to be the man in the middle, you are not snooping on any ones else connection. You are snooping on your own smile Or as you say: extract the key from the client binary. Any checksums and such can be faked. SSH is a bad example as it's a protocol and not a client. You can connect with any client that conforms to the protocol. Same with teeworlds.

Languages shapes the way we think, or don't.

19

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

Magnet wrote:

Program it, and the day there is a tournament, provide the server to the admin and let only registered players download the client. Change the key every day or every few games (that means restarting the server too).

You mean to change the private key ? This would imply that I must provide new clients every day. You really think it is needed ? By the way I think we can add a command to change the server public key, which is composed of two unsigned numbers, so that we don't have to restart the servers.

Magnet wrote:

But the positive side of that particular method is that it actually works for some time, but it is solely based on the trust you can put in the key.

You really think the key on the client can be reverse-engineered in 1 hour or so ?

Not Luck, Just Magic.

20

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

void wrote:

It's easy to be the man in the middle, you are not snooping on any ones else connection. You are snooping on your own smile Or as you say: extract the key from the client binary. Any checksums and such can be faked. SSH is a bad example as it's a protocol and not a client. You can connect with any client that conforms to the protocol. Same with teeworlds.

With RSA, I thought you needed to repeat a lot of handshakes to find the key because the private key was not fully sent over the network; I don't remember the specifics that's why I removed that quote from my post.

Dune wrote:

You really think the key on the client can be reverse-engineered in 1 hour or so ?

The first time no. After it's been done one time, yes. It's only a matter of having a program extracting it.

21

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

the man issue that its easy possible to cheat here is that this game is an open source game !!!!!

Teeworlds [ friends ] clan
Some YouTube Stuff about Teeworlds

22

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

jxsl13 wrote:

the man issue that its easy possible to cheat here is that this game is an open source game !!!!!

That, however, is not a real problem, as it doesn't affect vanilla and vanilla is the only official supported gametype.

23

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

it could drastically lower cheating, because most botters and votekickers don't make their cheats--they download it online in the form on a client. right?

24

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

Kottizen wrote:
jxsl13 wrote:

the man issue that its easy possible to cheat here is that this game is an open source game !!!!!

That, however, is not a real problem, as it doesn't affect vanilla and vanilla is the only official supported gametype.

It does, aimbot is not at all the only existing cheat in our Teeworld.

Not Luck, Just Magic.

25

Re: [SUGGESTION] RSA encrypted authentifications for 0.6

Dune wrote:
Kottizen wrote:
jxsl13 wrote:

the man issue that its easy possible to cheat here is that this game is an open source game !!!!!

That, however, is not a real problem, as it doesn't affect vanilla and vanilla is the only official supported gametype.

It does, aimbot is not at all the only existing cheat in our Teeworld.

-votehack
-multiclient
-rcon hack
-server crasher
-aimbot (also for vanilla -> shotgun hookin for example)
-spammer