Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Is this a sensible scheme for 2-way client/server communication? A client connects to a server. The server and client both generate RSA keys, and send over the public ones to each other. If the client wants to send a message, they encrypt it with the server's public key, send it over, and the server decrypts it. Vice versa with server -> client.

Does this make sense? Presumably breaking this is equivalent to breaking RSA, right? Is something like this ever used in practice? If not, what do alternatives do better?

share|improve this question
2  
1) It's expensive to encrypt all messages with RSA 2) You need to get all the details correct. Replay-attacks,... 3) Exchanging public keys is the hard problem. You need to figure out if the given public key belongs to the party you want to talk to. 4) Good transport encryption protocols offer forward-secrecy. Generating ephemeral RSA keys is a bit annoying compared to diffie-hellman keys. –  CodesInChaos Jun 9 '13 at 20:30
add comment

2 Answers

up vote 3 down vote accepted

The scheme you described is not a sensible scheme for 2-way client/server communication.

  • The new RSA public keys are not authenticated, thus you are not safe against active attackers, who could intercept the connection (or replace one of the partners). Those could read all the content, and/or replace it with their own.

  • If you would be using authenticated public keys (e.g. by certificates), the privacy would be given (i.e. an attacker couldn't read messages). But your messages have no authentication, and an active attacker could replace messages with their own ones, insert his ones, or drop messages.

  • You are using "ephemeral RSA key pairs" for each connection – this incurs a slight performance overhead, as generating new RSA key pairs is slightly expensive.

  • Using RSA for bulk encryption (and even more decryption) is really expensive, compared to a same-security block or stream cipher. Don't do this.

This is not essentially the same as what TLS is doing with RSA (assuming RSA key exchange):

  • In TLS the server's public key is accompanied by certificates, which allows the client to verify that it is really speaking to the right server. (The client is normally not authenticated.)

  • In TLS the client generates some random data and sends it by RSA to the server, to this some more random data from both client and server is mixed and used to produce symmetric keys for encryption and authentication using a symmetric cipher and a (symmetric) MAC algorithm. These are used for the actual communication (after some check to verify that both have the same keys).

share|improve this answer
add comment

Don't try to design this kind of protocol yourself; you will get it wrong.

Instead, use a well-vetted scheme, like TLS 1.2 with client authentication. This will help you avoid standard mistakes and will provide the security properties you are looking for.

For more details, see Don't roll your own crypto..

share|improve this answer
    
I'm not trying to roll anything, it was just for curiosity/understanding crypto better. –  alecbenzer Jun 12 '13 at 3:33
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.