4

I'm creating a mobile fast-paced game and currenly I'm working on login/registration/connecting. I'm trying to make it right so it won't mess in the future.

For now, I have read multiple articles of which method should I use to make a 'secure user session' between client and a server.

My goal is to use RSA only to exchange AES key and send packets with AES only

It should look like that:

Store the same public RSA key on all clients

Store one private RSA key on the server

Client sends the 'AES initialization data' to the server encrypted with public RSA. Server decrypts AES data with a private RSA key, stores AES data, encrypts AES data with AES data and sends back to the client.

Client receives AES data encrypted with the same AES data, decrypts and if everyhing is ok, handshake is done, we can securely send messages using AES data.

I'm using Java and I have RSA algorithm done, I checked packets with Wireshark, encrypted and decrypted and it works. The thing I can't finish is AES encryption cause I'm missing some knowledge.

I know that AES uses IV parameter which is used like a 'salt' in SHA. Basically I know how IV works, I read some, but I have no idea when and how many times should I send it.

Should IV be generated again and again with each packet or I should just generate one with a SecretAESKey, save it and use this pair to encrypt data and decrypt it?

I really learn quick so please don't judge me cause this question may look stupid to you.

Thanks for any help!

Improve this question
2
  • 2
    It looks like you're re-inventing TLS.. have you considered just using TLS? Commented Oct 7, 2016 at 19:18
  • 1
    What he said... Commented Oct 11, 2016 at 19:10

1 Answer 1

Reset to default
1

Don't do this, ever.

Inventing a secure protocol, even using known-good cryptographic primitives is extremely hard. Implementing a correctly designed protocol is still considered hard, even when using correctly implemented cryptographic primitives. Experienced people who work on crypto at Google/Microsoft/Apple have made bad mistakes with this stuff. They have learned from these mistakes and they all recommend you use the highest level misuse-resistant API you possibly can, instead of what you're doing which is using extremely low level API, badly.

From the questions you ask, you are very far from being qualified to do this kind of work for anything that will ever leave your computer.

It looks like you're trying to invent 90s crypto.

AES does not have an "IV parameter". You're asking about block cipher modes of operation (specifically CBC, which is not used in new protocols), and trying to decide whether to make the deterministic IV bug in TLS 1.0 CBC. Well guess what, the bug was brought up on the mailing list in the last century and has been fixed since then. And then CBC was deprecated in favor of AEAD modes, and now the industry is into misuse-resistant AEAD modes that don't break catastrophically when you repeat a nonce. Working alone without the best cryptographers pointing out the issues with your scheme, you might discover all those famous bugs by yourself, in a thousand years or so.

Since you haven't asked about how to combine encryption and MAC, I suspect you're doing unauthenticated encryption, which is known to be catastrophic. When you discover you need a MAC, you'll combine it badly with the encryption and the padding, like SSL did in the 90s.

Do you understand how secure padding of RSA works and why you need it?

You're trying to do RSA key exchange which has been disallowed in HTTP2 and TLS 1.3, for good reasons. Modern protocols provide forward secrecy.

Do you understand that index calculus is slowly killing RSA and classic DH and that's why people switched to ECC?

To summarise: Don't do this. Ever.

Use libsodium (or tweetnacl) instead. It is secure, fast, has a misuses resistant API, has been vetted by the best people. It is much, much better than TLS, even TLS 1.3 which is not standardized yet.

For educational purposes, I recommend doing cryptopals. You'll learn all you need to know about breaking bad crypto.

Improve this answer
2
  • As I can see, you're a professional. I'll just say that: I just can't imlement normal TLS, cause I can't combine it with my networking library. Kryonet is for sure the fastest networking library for my kind of game and it doesn't provide TLS. There's only one more UDP candidate, Netty, but it's slower and it's unacceptable cause I'm creating a real-time game on mobiles. One guy said to me to use HMAC to authenticate the data (solves your MAC argument) :D I just need to learn more on AES and pick the right algorithm (and the fastest one!). If you could help me choosing one, I'd be grateful. Commented Oct 12, 2016 at 7:35
  • @Spectre if you go this route, what you build will be 100% insecure. Look here: download.libsodium.org/doc/bindings_for_other_languages Commented Oct 12, 2016 at 14:59

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.