0

I read that why do we need E2EE and can't rely only on HTTPS for sending messages through a messaging app. The reason which i understood is when sender sends the message to the server, the TLS connection is associated with the server. TLS terminates at the server and whoever controls the server has the ability to view the messages since they are not encrypted.But, In this process when we send a message to the server, we are firstly encrypting the message with sender's private key and then with server's public key.

My question is why can't we encrypt the message with sender's private key and then receiver's public key? In this way, even if it reaches server, it won't be able to view anything since it can only be decrypted using receiver's private key.

If this is possible, then why do we use methods like Diffie Hellman key exchange?

shiwang
  • 103
  • 5
  • Are we talking about using the public keys that exist in the TLS or a separate mechanism like Signal? – kelalaka Aug 16 '20 at 19:48

4 Answers4

1

First of all, in TLS 1.2 RSA is not used for encryption or decryption of the messages. It can be used for authentication and key exchange but not actual encryption. TLS utilizes symmetric cryptography for the encryption of the payload. Generally, it is considered a good practice to use RSA only for the authentication part, as the keys exchanged using RSA are not ephemeral. It means that if anyone was ever able to decrypt captured communication he would be able to find the symmetric keys used to encrypt the payload and obtain the data exchange between nodes. One of the reasons why we are using encryption is a fact that it is very easy to record the communication of the network.

We are currently pushing towards "perfect forward secrecy" which can be only achieved with ephemeral keys. For that to take place we need to exchange keys without sending them in the communication. It is possible to exchange symmetric keys without sending them over the network, we are using Diffie-Hellman (or EC variant of it) key exchange for that.

Your problem boils down to the fact that the TLS session is between the server and the sender, not the sender and recipient. Depending on your level of trust in the server you may consider it man in the middle. This is the reason why E2EE is used. You don't want to exchange the secrets using symmetric crypto cause if it ever gets decrypted your communication is out in the open. It doesn't really matter if the asymmetric crypto is end to end in this case or sender -> server, server -> recipient.

Bruno Rohée
  • 5,221
  • 28
  • 39
nethero
  • 482
  • 2
  • 6
1

It wouldn't work. In order for the sender to complete a TLS handshake with the server, the server needs to have the private key associated with the public key that the server presents to the client (sender). So, if the server presents the receiver's public key to the sender, the sender would not be able to complete a TLS handshake with the server, unless the server also has the receiver's private key.

mti2935
  • 19,868
  • 2
  • 45
  • 64
1

My question is why can't we encrypt the message with sender's private key and then receiver's public key? In this way, even if it reaches server, it won't be able to view anything since it can only be decrypted using receiver's private key.

That is essentially how E2E encryption works, if by "encrypt with the sender's private key" you mean either a digital signature or a key exchange like Diffie-Hellman where both the sender and receiver's keys are combined.

For example, the signal protocol (and corresponding apps) do have a server, but since messages are E2E encrypted in basically the way you describe, the server can't read them.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • I know this question is 2 years old, but it came up on the front page, and I though I could add an answer different from the existing ones. – Mike Ounsworth Jul 06 '22 at 18:20
  • I was looking for why it popped up again…. Still good addition. – LvB Jul 06 '22 at 20:55
0

My question is why can't we encrypt the message with sender's private key and then receiver's public key? In this way, even if it reaches server, it won't be able to view anything since it can only be decrypted using receiver's private key.

You absolutely can do that. The server would in this case only know recipient, and possibly sender, but not content of the message.

vidarlo
  • 12,850
  • 2
  • 35
  • 47
  • If this is possible, then why do we use methods like Diffie Hellman key exchange? – shiwang Aug 16 '20 at 11:48
  • DH is a method for agreeing upon a key without prior communication, even if the communication channel is monitored by an eavesdropper. I would suggest [this question](https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work) as a good starting point. – vidarlo Aug 16 '20 at 11:54
  • I found that the implementation I was talking about for HTTPS was using only RSA. Although, we don't normally use RSA alone because of perfect forward secrecy issue. That's where key exchange methods like Diffie Hellman comes into picture which solves that issue. Am I right? – shiwang Aug 16 '20 at 13:02