1

Actual implimentaton will be in android but this is more about general security than actual implimentaton details. I'm making an end-to-end encrypted chat app and I know that in order to send encrypted messages you have to encrypt the message with the receiver's public key and they will decrypt it with their private key.

What I'm stuck on is that once I store this encrypted message on the server, the sender will not be able to read their own sent messages because the messages will require the receiver's private key - which they wont have access to. The result is that inside the chat app the sender wont be able to see the actual contents of any of the messages they send, they would only be able to view messages that are sent to them from other users.

Clearly I'd like users to be able to see the entirety of the conversation history, not just recieved messages. I think what I might be getting at is how do I can I store sent messages so that they can be decrypted by both the sender and receiver? Or if I'm thinking about it incorrectly then what is the correct way to solve this problem?

Improve this question

1 Answer 1

Reset to default
0

Create a symmetric key, encrypt the symmetric key with receiver's key, encrypt every message with the symmetric key. On the sender side, store the symmetric key together with the message.

Or encrypt the message with the receiver's key, send it. Encrypt same message with sender's key and store it.

Improve this answer
5
  • 2
    Actually, it’s common to encrypt the message with a symmetric key, then encrypt the symmetric key twice with both the recipient‘s and the sender‘s public key, then store both with the message.
    – not2savvy
    Jun 2, 2019 at 7:32
  • This was exactly what I was looking for thank you
    – Jake McGhee
    Jun 2, 2019 at 10:18
  • @not2savvy I ended up implementing your solution and it worked very well. One question someone had about my project but I couldn't quite answer is why is this implementation preferable to just encrypting the message itself twice with RSA - once with the sender's public key and again with the receiver's public key and the pair of encrypted messages together. Like I said your implementation works great - I am just trying to understand better the advantages / disadvantages of other implementations. Thank you
    – Jake McGhee
    Jun 27, 2019 at 18:45
  • @JakeMcGhee, glad to hear it works well. The main reason for not using the asymmetric encryption with the public key directly is that this does not scale well. Asymmetric encryption algorithms are slower by a factor of 100-10,000 compared to symmetric ones. The message size can differ significantly in size, affecting performance. The solution, called "hybrid encryption", is to use the efficiency of the symmetric algorithm for the message, and use asymmetric encryption for the symmetric key. This scales much better because the key size does not vary.
    – not2savvy
    Jun 28, 2019 at 9:51
  • @not2savvy I see, that makes sense. With hybrid encryption we are using faster symmetric encryption for messages that can get very long and only using slower asymmetric encryption for key sizes which stay relatively the same size. Thank you very much!
    – Jake McGhee
    Jun 29, 2019 at 16:40

You must log in to answer this question.

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