Jump to content
  • Advertisement
Sign in to follow this  
Codejack

Rijndael Algorithm and Security

This topic is 4075 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, I am designing a simple client / server game to learn about network programming. In the "login" procedure the client sends the login credentials to the server encrypted using the Rijndael algorithm (a.k.a AES). For other data transmissions I anticipate using XTEA (due to it being faster) with a session key negotiated during the login phase. My concern is that to use Rijndael, the client needs to know the pass phrase, salt value, initiation vector and number of iteration for the algorithm etc in order to encrypt the data to send to the server. How can I prevent these values being discovered by someone who reverse engineers the client?

Share this post


Link to post
Share on other sites
Advertisement
One way or another, those values are going to need to exist on the client machine (usually in memory). To my knowledge, Rijndael itself only really needs a key and to know the key size and block size to be used (if you are using AES, the block size is locked at 128-bit, and keys of either 128, 192, or 256). If you want you could use a public/private key system to transmit the rijndael key to the client computer and keep it memory resident. At least this way, its not just sitting in a file somewhere on the client machine, and its also not being transmitted over the network in plaintext.

Share this post


Link to post
Share on other sites
Quote:
One way or another, those values are going to need to exist on the client machine (usually in memory). To my knowledge, Rijndael itself only really needs a key and to know the key size and block size to be used (if you are using AES, the block size is locked at 128-bit, and keys of either 128, 192, or 256). If you want you could use a public/private key system to transmit the rijndael key to the client computer and keep it memory resident. At least this way, its not just sitting in a file somewhere on the client machine, and its also not being transmitted over the network in plaintext.
Interesting... thanks for your response. I had a look in to using a public/private key system and settled on the RSA algorithm of which there are some excellent .Net based examples on the web.

Do you have any thoughts on using this public/private key system for the login procedure itself rather than to pass the Rijndael key to the client? The client could encrypt the login credentials with the public key which only the server could then decrypt. Assuimg, the server isn't broken in to and the private key discovered (maybe it is hardcoded in the server application to make this harder)...

Share this post


Link to post
Share on other sites
The plain and simple fact is that is someone has access to the computer, they can likely get the code, even if its hardcoded (sometimes its even easier this way). Quick use of a hex editor and they have extracted the private key. You can do your best to prevent hacking (and this has been the topic of many a thread), but in the end if someone is determined enough, they are going to hack it. Your goal is not to make it hack proof (this is just impossible), just to make it as secure as possible, while not sacrificing the functionality.

The individual keys still need to exist somewhere. And because they do, they can be accessed. The public/private key system is more for just establishing a connection without sending secret keys over a channel in plaintext. Really, you don't even need a server set of keyz. You can generate this for the client only, since all you really need to do is send the private rijndael key over the encrypted channel (if you want to use rijndael for the main code). You could actually generate random rijndael keys for each client when they connect as well, so they key changes everytime they login.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!