I have a website where a registered user can exchange any number of offline messages with a guest. The guest only has to enter his e-mail address and should not have to create an account. The messages should be stored encrypted on the server. If there is a new message for the guest, he should only receive a one-time link by e-mail, with which he can decrypt the messages.

The requirement should only be that a hacker who steals the database cannot decrypt the messages. I thought I'd use a public/private key method and attach the private key as a GET parameter to the https link. It is never stored anywhere at any time and is only in RAM. The problem is that the private key is very long and of course I don't feel good about transferring the private key to the server.

Is there another (better) way, without any password input, or client software, just with a link via email?

  • Can the user and guest share some password preemptively through a separate trusted channel? – Luke Park Nov 21 '19 at 21:12
  • No, the guest initiates the conversation via the website and it should be avoided that the effort becomes too high for him. Therefore no registration. The communication is also not particularly worth protecting. It is only privacy by design. – root66 Nov 21 '19 at 22:10
  • 1
    You could generate the link on the client-side (so the private key never reaches your server) and allow them to communicate this link to the client however they see fit (their own email account, slack etc.) – Luke Park Nov 21 '19 at 22:13
  • How can I decrypt the messages if the private key is not transferred to the server? GET parameters are the only way to get data from the e-mail program into the browser. POST does not work reliably. Even if a Javascript decrypts the data in the browser, the GET request would send the private key to the server. – root66 Nov 21 '19 at 22:23

There seems to be a flaw in the design of this system.

If you want to guarantee (to a reasonable extent) that the only person who reads the message is the user who enters their e-mail address, then the user must provide their public key and your server should encrypt the message using that key. It will be responsibility of users to decrypt the messages.

Otherwise something else needs to decrypt messages for users and therefore needs to have access to private keys. If your threat model includes the risk of the database being stolen than the same way that other system that will be decrypting messages could also be stolen, including the keys.

Is there another (better) way, without any password input, or client software, just with a link via email?

In this case the e-mail becomes "the key" because it is the only information that is required to obtain the cleartext message. Therefore you system becomes as (in)secure as the e-mail message and its delivery.


If you want that only the user can read the message, and that a hacker cannot read it in the database, this means you (your application) should also have no possibility to read the messages. And if you cannot read them, what sens it make to keep them in the database? I'd suggest that as soon as you get a new message for user you encrypt it and send. May be one reason could be that if user has lost this email, you can resend it. This is OK. Keeping encrypted Email is not a problem.

But i you want that your server can read all the user messages at any time, then you cannot of course keep the messages encrypted with users key. You have then use a separate key that is known to server only. Server encrypts and decrypts all messages in database with this key. When a message needs to be sent to user, server decrypts it with its, then encrypts with user's public key and sends it to user. If an attacker obtains your database, he will need also a password that server is using for encryption/decryption. You can use HSM to mitigate it.

To encryption: The most reliable solution would be to use PKIs. You can provide a web application, that during user registration generates key pair in browser and sends public key to your server. Your server uses later on this key to encrypt messages to this user.


Each registered user should have a Public Key stored on the server and a cryptosystem which cobines public and symmetric encryption should be used.

Then, anyone would be able to exchange any number of offline messages with any registered user. Each registered user would be able to answer those messages if you use ElGamal Cryptosystem which combines Public and Symmetric Encryption. Elgamal is very easy and amazing - https://en.wikipedia.org/wiki/ElGamal_encryption.

Each public key is generated in the following way: Take a secret x from a ciclic group and compute the public key $X = g^x$. All information about the ciclic group is also public (i.e. saved on the server).

Each sender (guest or not) generates an ephemeral secret key y from the ciclic group and computes a correspondig ephemeral public key $Y = g^x$.

The encryption key can only be generated by sender ($K = X^y$) and receiver ($K = Y^x$). Y should be attached to the message.

Notice ElGamal uses the concept of Diffie-Hellman without the Man-in-the-middle flaw - even the server, which acts as the intermediate channel to share the messages, is not able to get K.


The fundamental issues as I see it are:

  1. The guest only has to enter his e-mail address and should not have to create an account

This suggests the guest is unregistered (hence guest) so no attributable encryption keys.

  1. a hacker who steals the database cannot decrypt the messages

This is fairly vague and begs the question of what exactly is in the potentially stolen database or are you actually referring to the entire system theft?

If the concern is just the database then keeping the keys elsewhere meets the criteria. This could be as simple as a fixed key in an external process, or an external key process based upon the guest email.

If the concern is actually whole system theft and not just the database, then a similar approach is possible with the requirement that any keys are loaded and maintained only in memory from an external source that is removed upon start up.

If the concern is complete run time compromise with full memory access by the attacker, then I have no idea!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy