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?

Improve this question
1
  • Are we talking about using the public keys that exist in the TLS or a separate mechanism like Signal?
    – kelalaka
    Aug 16, 2020 at 19:48

4 Answers 4

Reset to default
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.

Improve this answer
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.

Improve this answer
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.

Improve this answer
2
  • 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 6, 2022 at 18:20
  • I was looking for why it popped up again…. Still good addition.
    – LvB
    Jul 6, 2022 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.

Improve this answer
3
  • If this is possible, then why do we use methods like Diffie Hellman key exchange?
    – shiwang
    Aug 16, 2020 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 as a good starting point.
    – vidarlo
    Aug 16, 2020 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, 2020 at 13:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .