Is it safe to reuse a symmetric key when using asymmetric encryption?

Question

I've written a C# Library that I hope will be used for security purposes in a commercial application. The application will communicate through the internet and not on an internal network. I am using RSA for Asymmetric Encryption and Rijndael for Symmetric Encryption. Currently the process I am using is as follows:

• The Client sends it's RSA Public Key to the server.
• The Server encrypts the Rijndael Symmetric Key using the Public Key and sends the result to the client.
• The client decrypts the Symmetric Key and stores it.
• When either party sends any data, a new IV is generated each time, but the Symmetric Key remains the same.

I expect the lifespan of the connection between the Client and Server to last for at most 10 - 20 exchanges of information before the connection closes, thus being 10 - 20 sets of data encrypted with the same key, but with a different IV. Past this, the Symmetric Key is destroyed. Both Asymmetric Keys, the Symmetric Key and IV are all generated by the classes I'm using.

Is what I am doing safe? Are there any major security flaws I'm missing?

EDIT: I send the IV along with the Rijndael Encrypted data, where it is seperated from the data and then used by the receiving party to decrypt the data. I have read elsewhere that this is safe practice?

Answer 1

The use of the AES key many times is not a problem. However, there is a fundamental flaw with your solution. The server has no way of validating that it received the client's authentic public key. In particular, a man-in-the-middle can capture the client's public key, can forward its own public key to the server, and can then decrypt all traffic sent by each party (since it will be able to decrypt the AES key). Also, the client cannot know that it is talking to the authentic server at any stage.

Apart from that, you lose a lot of properties that people like to have in such protocols, like forward security.

In general, it's not a good idea to make up your own protocols (no matter how simple). My recommendation is to just use TLS v1.2 with a forward-secure cipher suite. The best to use are TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, or TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. However, you still have to solve the problem of somehow enabling the parties to identify each other, and to be sure that the correct public key is used. This is handled by using certificates.

Answer 2

Why not use the mature, analysed, and successful pattern of PGP communications?

First each party exchange the public keys of both the Client and Server. Even better out of band verify them depending on your threat model (i.e. phone call or some other independent method of verification of each side's identity and public key fingerprints) which prevents man-in-the-middle attacks.

Next for each message encrypt a new random AES key and IV and SHA2 hash of the data payload with the Public RSA key of the opposing party and sign it. This allows each side to verify and authenticate who sent the data. You also get warnings that the hash/checksum failed and to error out and not process the data recieved. The data would continue as before appended after AES encryption with a unique key. Then you also don't need to store AES keys anywhere. You are also now verifying each side of the communication as a bonus.

Do not use a fixed IV. It can have seriously negative consequences. That said, a random 128-bit IV stored in plaintext is typically what you want. The IV can be known to an attacker without breaking security.

CBC mode has extra-strict requirements for the IV. Generating it with a cryptographically secure pseudorandom number generator is best practice

CTR mode is safer, CBC has concerns about padding attacks

Is AES in CBC mode secure if a known and/or fixed IV is used?