Join Log in
Score:1
avatar Crypto

Is it secure to use RSA to exchange AES key?

jp flag
user99011

I have to create a Client-Server Application using Java and I want to make the communication secure. I thought to use AES to encrypt the messages and for key exchange I make the next steps:

  • Client generates RSA keys and send public key to server
  • Server will encrypt the AES key with RSA Public key (AES key is generated random for every client)
  • Client decrypt the message with its RSA Private key and then all messages will be encrypted with AES

My question is: is it a good practice ?

124
0 + 0
rsa
Swashbuckler avatar
mc flag
Swashbuckler
Basically, what you've described is key wrapping using a public/private key. It can also be done with symmetric keys as well. Rather than invent your own way of doing it and possibly making a mistake you should take an existing implementation from a good crypto library and use that.
3
Reply
Maarten Bodewes avatar
in flag
Maarten Bodewes
The real question is: how are you going to trust the public key that you receive? It might be one created by an adversary. This is usually where PKI comes into play - quite often PKIX with X.509 certificates as used in e.g. your browser for TLS (server) authentication.
3
Reply
Maarten Bodewes avatar
in flag
Maarten Bodewes
Otherwise yes, RSA can be used to perform key establishment, with the main drawback that key pair generation is pretty slow - so if you want to use a new key pair for each connect for forward security, then you may have an efficiency problem. This is why commonly (EC)DH is used instead.
1
Reply
kelalaka avatar
in flag
kelalaka
Does this answer your question? [Is direct RSA encryption of AES keys secure?](https://crypto.stackexchange.com/questions/76855/is-direct-rsa-encryption-of-aes-keys-secure)
2
Reply
Score:2
avatar Crypto
kr flag
mentallurg

No, it is not a good practice.

  1. It is prone to man in the middle attack. When server receives a public key, it does not know if this key comes from a client or from the "man in the middle". Thus, the "man in the middle" can intercept the traffic between client and server, for client it can simulate server, for server it can simulate client. Thus, the whole communication will be 1) known to MitM and 2) data sent in both directions can be modified by MitM.
  • --> You can avoid it, if you authenticate clients to server or authenticate server to clients by using public key certificates.
  1. It is prone to replay attack. Suppose a client sends command "transfer 1000 USD to account 123456789". This can be legitimate operation. But if an attacker intercepts the traffic and resends it within relatively short time (so that the server still uses the same key for AES encryption for this client), then server will not be able to distinguish, if this traffic comes from the client of from the attacker, and will execute the command. Even if you authenticate clients to server or authenticate server to clients, this problem will still persist.
  • --> You can avoid it, if you use nonce.

  1. The good thing: Your current approach has relatively good forward secrecy: past sessions are protected against future compromises of client keys or session passwords. But if you address the problem 1 mentioned above (authentication) and start using the same RSA key over multiple sessions, then you will lose forward secrecy. If an attacker obtains private key, all past sessions can be decrypted. To prevent it, you will need further measures, e.g. ephemeral Diffie-Hellman key exchange.

  2. Independent on all the problems above, it is important to properly use RSA, as @kelalaka mentioned. See details here and here.

Thus, it may be much more secure to use TLS implementation provided by Java, instead of implementing your own protocol.

0 + 0
cn flag
tylo
Maybe you can add: for TLS 1.3, the standardization committee threw out RSA for key agreement completely. What the history around PKCS#1 and Bleichenbacher attacks has shown: RSA might just be a bad choice for key exchange, and it's not worth the hassle to get it right, when all problems are so much easier to fix when using other methods
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.