Jump to content

  • Log In with Google      Sign In   
  • Create Account

Encryption with time played


Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.


  • You cannot reply to this topic
10 replies to this topic

#1 Butabee   Members   -  Reputation: 273

Like
0Likes
Like

Posted 23 March 2014 - 04:11 AM

I was thinking of encrypting data with total time played down to the minute. The time would be kept track of seperately on the client and the server so it never has to be transmitted.

 

I'm not sure how secure it would be so I was hoping for some input.



#2 ProtectedMode   Members   -  Reputation: 1339

Like
0Likes
Like

Posted 23 March 2014 - 04:13 AM

Your question is really vague. What data are you encrypting? What kind of server and client? Who encrypts the data? For what reason are you encrypting data?



#3 Butabee   Members   -  Reputation: 273

Like
0Likes
Like

Posted 23 March 2014 - 04:34 AM

Passwords. Custom game server and client. Client encypts, server decrypts. I don't want to transfer plaintext passwords in case of sniffing.



#4 Brother Bob   Moderators   -  Reputation: 9943

Like
5Likes
Like

Posted 23 March 2014 - 04:48 AM

Use a proper and tested encryption mechanism instead of inventing your own. A real encryption mechanism is safe because it is safe by design and not because the hacker can't figure out which methods you use.

 

Besides, time is not a very secret either; the hacker also knows the time. But there's also the problem of keeping the clients in sync. Just using the time down to the minute does save you the problem of keeping them in sync or handling timing issues. For example, the transit time of a package over a network is not zero, so how would you for example handle time stamps which ticks to the next minute after the package is sent but before it is received at the other end?



#5 Butabee   Members   -  Reputation: 273

Like
0Likes
Like

Posted 23 March 2014 - 05:11 AM

I could try a minute behind or ahead if the decrypted message doesn't match the password, which I guess makes it down to 3 minutes. Unless the hacker was monitoring a player from his very fist connection ever, he'd have to make a pretty good guess to get the total time played. After an incorrect guess in the 3 minute range, I could just ban.

 

I'm using lidgren for my networking and would be using the minutes played as the encryption key.

 

What existing encryption can I use with lidgren?



#6 ProtectedMode   Members   -  Reputation: 1339

Like
0Likes
Like

Posted 23 March 2014 - 05:25 AM

Or you can use asymmetrical encryption like RSA. Then you can let the server send the encryption key for a symmetrical encryption protocol. I don't see the need to create some custom protocol...



#7 wintertime   Crossbones+   -  Reputation: 3775

Like
0Likes
Like

Posted 23 March 2014 - 06:25 AM

Wouldn't it go like this:

- time 0: player joins game and sends pw

- hacker knows time is most likely 0 and "decrypts" the pw

 

Thats a stupid encryption method.



#8 Butabee   Members   -  Reputation: 273

Like
0Likes
Like

Posted 23 March 2014 - 06:30 AM

Wouldn't it go like this:

- time 0: player joins game and sends pw

- hacker knows time is most likely 0 and "decrypts" the pw

 

Thats a stupid encryption method.

That would only work for a players very fist session ever... which I already mentioned.

 

Anywas since all I'm gonna do is catch flak for mentioning this I'll just use asymmetrical encryption.



#9 Mussi   Crossbones+   -  Reputation: 3771

Like
0Likes
Like

Posted 23 March 2014 - 06:58 AM

I was thinking of encrypting data with total time played down to the minute. The time would be kept track of seperately on the client and the server so it never has to be transmitted.

 

I'm not sure how secure it would be so I was hoping for some input.

You'd have a very limited pool of keys, you could brute force all of them in less than a second.



#10 hplus0603   Moderators   -  Reputation: 10072

Like
3Likes
Like

Posted 23 March 2014 - 12:01 PM

If the player starts playing from another machine, how would the new machine know the client-side secret of the old machine? No matter whether it's something easily guessable like "time" or something harder like a strong nonce?

Cryptography is really, really, hard. Even the best in the world make mistakes, as seen in vulnerabilities in packages like RSA or OpenSSL. It's clear that you have not spent the time necessary to actually read anywhere near sufficiently on what the challenges are and what the strengths and weaknesses are of various designs.

My sincere and helpful advice to you right now is: STOP!
If you're trying to protect your game against some particular kind of attack, then use an existing cryptosystem that is designed to protect against that attack. HTTPS is one; OpenSSL is another.
If you're trying to learn how crypto works and what the different threats and responses are, then pick up a high-quality textbook and actually read about what all attackers already know.
enum Bool { True, False, FileNotFound };

#11 frob   Moderators   -  Reputation: 39078

Like
1Likes
Like

Posted 24 March 2014 - 12:50 AM

For Butabee, I cannot imagine anything your protection scheme attacks against that cannot be defeated by old fashioned methods. A simple memory inspector can compromise just about any game client.

 

So what if your data is encrypted when you write it on disk, and the values are encrypted when traveling across the wire.  They are open and accessible during processing. If the data is available on the client machine in any way whatsoever, a skilled attacker can find it and use it.


Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.





Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.




PARTNERS