2

I was thinking about this concept and realized that when a user is decrypting an email on the frontend of the email service, won't the server theoretically be able to "see" the private key and the decrypted contents?

Like, once the email is fully decrypted and the user can see its contents, since the contents are just text which are in a UI which is hosted on a server, cant the server theoretically see the contents (or if the owner of the servers had intent to see the emails)?

Thank you

migrated from crypto.stackexchange.com Oct 21 '18 at 11:12

This question came from our site for software developers, mathematicians and others interested in cryptography.

  • Yes, because you already trusted them and give your private key. But it is not your private key anymore. Any example of such e-mail service that decrypts on the e-mail server? – kelalaka Oct 21 '18 at 8:25
  • You are always at the mercy of the manufacturer / deliverer of the software you are using when it comes to security, which includes end-to-end encryption. – SEJPM Oct 21 '18 at 8:37
3

Whatever can decrypt can get hold of the plaintext. For encrypted email that includes "the server" or not, depending on the setup, which is not clear in the question.

With what we can imagine of the setup, for sure the plaintext is available not only to the user, but also on the screen, and in the computer connected to that. The plaintext is thus vulnerable to whoever can see the screen, tap its cable, penetrate the user's computer, or decide the programs it runs in the first place. That minimal chain of trust needs not extend to "the server" (as in say an IMAP server on which the emails are stored at rest), but it can extend to that, and sometime does. The question does not allow to tell, in particular because it does not specify what "the frontend of the email service" is.

The conceptually simplest and (thus) safest way to practice email decryption is that it is carried on the recipient's own trusted computer, which is the only machine using the user's private key. In this case "the server" can not see the decrypted email. In the basic form of that, encrypted email really is a an attachment, extracted and deciphered by a local program (e.g. GnuPG), and displayed. That can be integrated in the email client program (e.g. Thunderbird, or Outlook-the-user-side-program), perhaps thru a plugin. And that can be integrated in the email syntax so that the encrypted email does not appear as an attachment. Each step away from simplicity comes with potentially decreased security; that's one of the lessons of efail (archive; main site is currently down, because security is hard to conciliate with functionality).

Setups in which the server can intercept the decrypted email include anything where the user interface is a standard web browser. Adding a plugin handling the decryption locally with a local private key, perhaps a Smart Card or Trusted Platform Module can be a step in the right direction; but that might also be mere security theater if the software orchestrating the flow of information comes from the server: the server can still send a modified software that will give access to the email. In practice, whatever can decide how decryption is performed can get hold of the plaintext (with few exceptions not found in common practice: like there is a data diode in place to prevent the decrypted plaintext to flow back to the server).

When the user is using a web browser or a dedicated program of unknown origin and closed design or/and source, it is in practice next to impossible to tell if "the server" can get the decrypted email, thus the rational action is to consider that possible.

  • 1
    I think I get what you're trying to say here, but I'm not certain.. You can't "decrypt plaintext", and you can intercept ciphertext or plaintext regardless of if its.. well.. enciphered or plain. – xorist Oct 21 '18 at 16:08
  • @xorist: my English is that of a Frenchy.. Is the modified answer more satisfactory? – fgrieu Oct 21 '18 at 17:32

Your Answer

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