0

I am trying to write a web application with chat system which stores chat messages in a mongoDB database on server side.

I generate a private and public key on server side and encrypt the messages using the private key and store them in my mongoDB database. As much as I have figured, you give public key to everyone but you should not share private key yet messages can be decrypted only using private key as this article suggests.

yet obviously client must be able to decrypt the encrypted message so it can show it to user.

Now we are in a situation where:

  • the user must have the private key to decrypt the information.
  • the private key should not be passed around as comments on this post suggest

How should one deal with this contradiction?

  • Have you looked up the design patterns for this already? – schroeder Mar 02 '23 at 13:25
  • Private key should be generated by the client, and should never leave the client. See https://security.stackexchange.com/questions/247918/need-some-clarification-regards-end-to-end-encryption-process and https://crypto.stackexchange.com/questions/35530/where-and-how-to-store-private-keys-in-web-applications-for-private-messaging-wi for more info. – mti2935 Mar 02 '23 at 14:53

1 Answers1

0

There are two separate issues you describe here, protection in transit (the actual sending/receiving) and protection at rest (in the database)

For both parts solutions exist already, the use of home-grown encryption solutions is strongly discouraged. As far as I know MongoDB offers solutions for both:


In general, you can not secure a two-way communication purely with asymmetric encryption if only one side has a key pair. As you wrote, the private key must only be kept on the system that generated it.

Either the clients need to generate a key pair as well, each system can then encrypt their messages with the public key of the destination.

However, in most cases transport encryption is not done this way for a couple of reasons:

  1. Asymmetric encryption is slow
  2. In most cases it can not be assumed that all client have an own compatible key pair
  3. Similar to symmetric encryption, key exchange is an issue. In most cases the client can verify the server as servers usually have certificates from trusted CAs, for clients this is rare outside enterprise environments.
  4. Increased attack surface as the same key is used for all messages.

To solve (some of) these issues, the client usually generates a symmetric key, encrypts it with the private key of the server and transmits it.

The server then decrypts the secret key and uses it to encrypt the actual messages for one communication session.

fleitner
  • 538
  • 3
  • 12