What should I exchange with the server when I generate my AES 256 key?

Question

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!

Answer 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.