CODEWITHSUNDEEP
c#securityencryptioncryptography
Camilo Terevinto
Camilo Terevinto

Reputation: 32058

Properly generating RSA+AES keys

For learning purposes, I'm creating a chat application where the connections are done via SSL/TLS, and the messages are encrypted using AES-CBC-256 and the AES keys are encrypted with RSA-2048.

The AES key is randomly generated (AesProvider.GenerateKey()) per user per session (which means one key for every person an user is chatting with) and the IV is randomly generated (AesProvider.GenerateIV()) by passing in the key generated, each time a message is created (before being sent).
On the RSA side, I'm generating a secure random session name to store the private keys generated in containers, and sending out the public key. I'm also using the same model (one key pair per user per session) as in AES.

I should also state that I'm using HMAC-SHA512 to hash the messages and sending the HMAC key encrypted using the same public key that the AES key/Iv gets encrypted with. Since I've read that it doesn't need to be regenerated often, I'm planning on regenerate the HMAC key every 5000 or 10000 calls.

Questions:
1) Should I be creating only one RSA key pair per user and use it for all sessions, or is it good how it is right now?
2) Is using the same AES key and only changing the IV like explained above considered secure?

Upvotes: 1

Views: 2026

Answers (1)

Oguz Ozgul
Oguz Ozgul

Reputation: 7187

Not much to answer because what you are doing is the best practice aready.

Some notes though;

RSA key pairs per session is not required (and generating the key is expensve).

You can have only one 2048 bit strong RSA key throughout the lifecycle of your application or for years, since this is what even the most security demanding web applications like e-commerce sites or financial applications do.

You should have a random AES key/IV pair for each session, that is fine.

It is better to have one HMAC key per session (not process wide) since you are sending the key securely (RSA encrypted) and you are also sending the HMAC value securely (AES encrypted) on the wire.

Changing only the IV is almost equal to changing the key and IV (in a sense) because the encrypted output will be different for the same content if you change the IV.

One note however. To prevent a man-in-the-middle attack mimicking your server certificate, is your client code validating the certificate through means of signature checking, or is it just the public key that you are sending without any validation on the client side?

You should have either a self-signed persistent certificate or generate the random certificate (RSA Key Pair) as is issued by the persistent certificate (eg, CN=FrozenDeathChatServer) where the clients during installation of your client software install under the trusted root certificate authorities.

Upvotes: 1

Related Questions