I'm using an email service with encryption option and I need to send an encrypted email. So if I need my letter to be sent encrypted, I need to take my receiver's public encryption key and apply it to my letter with an encryption function. The point is my service has built-in encryption, thus generating my own private-public key pairs for each of my receivers, but the receiver is using a simple email service, which doesn't generate a public key for him by default. So if I have a public key, will my receiver's email service automatically generate a public key for his mailbox so that my letter to him could be encrypted?

  • wrt, 'will my receiver's email service automatically generate a public key for his mailbox ' - if so, then this would not be end-to-end encryption. The public key is derived from the private key, so this means that the receiver's email service would need to generate the private key first, then derive the public key from the private key. So, the recipient's email service would have the private key, therefore they would have the ability to decrypt messages sent to the recipient encrypted with the public key.
    – mti2935
    May 12, 2022 at 14:44
  • That's a point. I've included it in the answer.
    – Summit2
    May 14, 2022 at 14:02
  • Nice answer (+1). If you are looking for a simple browser-based tool to send/receive messages with end-to-end encryption, have a look at encryptedsend.com (fd, I am the developer).
    – mti2935
    May 15, 2022 at 12:55

2 Answers 2


So if I have a public key, will my receiver's email service automatically generate a public key for his mailbox so that my letter to him could be encrypted?

No, it would be like shipping a letter to someone in a locked box with the key fastened on the side.

The receiver does not have a public key, so if your provider creates one, it's the provider's key, not the receiver's key. If the provider sends the receiver the private key, everyone in the way can have a copy too. It could not send the receiver the key and decrypt your message and store the plaintext version of it.

It probably only uses the encryption function to send email to other people that are using the same provider as their public keys are available. If you send email to someone that isn't client of your provider, they will only send the plaintext version. So if you want to send encrypted email, you will have to get the recipient's public key yourself and encrypt before sending.


I figured it out. Even if receiver's service could generate his public key and hand it over to me for encrypting the letter, then this service would also have the private key and thus be able to decrypt this letter by itself, which makes the encryption senseless. But actually it most probably can't do this generation because most email services don't have a common encryption protocol implemented in them (or don't provide it to everyone).

But I also read the docs for my service and found out that for communication with other services it doesn't use public keys, but uses a usual symmetric scheme where you encrypt the letter with a key and then have to transmit this key to the receiver for the decryption via some other channel. And in order that your receiver could read the letter the service doesn't actually send him the encrypted letter, but instead sends a link to its own page where he can input the key and this key will be applied to the letter for decrypting and reading.

So I see that this service is much more convenient than traditional desktop clients with encryption programs attached to them (both for sender and receiver). It's called Tutanota by the way.

  • It would have been nice if you had included the system in your question, too. Their FAQ keeps bragging about how innovative their encryption scheme is, but doesn't tell much about the technical details. May 14, 2022 at 12:47
  • What do you mean by including the system? Should I have mentioned Tutanota in the question text?
    – Summit2
    May 14, 2022 at 14:01
  • Exactly. If the encryption scheme is different from the standards like S/MIME (RFC 8551) & OpenPGP Message Format (RFC 4880), you should have mentioned it. May 14, 2022 at 14:07
  • Actually it wasn't relevant in the question because whatever their standard is (I understood that they've created their own modification of PGP), it is not the same for the receiver, so the answer would be the same - that the public key wouldn't be generated.
    – Summit2
    May 14, 2022 at 15:26
  • Yes, but it is still better to evaluate an actual system than one's depiction of it. May 14, 2022 at 15:47

You must log in to answer this question.

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