5
$\begingroup$

One common complaint about GPG-encrypted e-mail is that it doesn't provide forward secrecy; however with opportunistic TLS becoming increasingly common in both IMAP and SMTP, it's not unreasonable to expect that e-mail sent from one message transfer agent (MTA) to another is done over a TLS protocol that utilizes (EC)DHE—by far the biggest e-mail provider, Gmail, is configured to send and receive e-mail this way by default. Thus if communication between mail user agents (MUAs) and message submission agents, MUAs and message delivery agents, and MTAs and MTAs is done using such a protocol (e.g., TLS 1.3); then even if the GPG key that was used to encrypt the e-mail is fairly static, shouldn't this constitute as "forward secrecy"?

It seems to me that the only way to decrypt someone else's e-mail is if the end-point device has been compromised. This is also true for Signal though. Am I mistaken?

$\endgroup$
  • 1
    $\begingroup$ Yes, having a ephemeral cipher in startls will provide forward secrecy for the data in transit, but not while storage or forwarding inside the MTAs. However often TLS with SMTP does no strict validation and is therefore suspectible to Monsters in the Middle. $\endgroup$ – eckes Oct 14 at 19:11
21
$\begingroup$

Forward secrecy is a confusing term that should be abandoned, especially the meaningless but value-loaded variant ‘perfect forward secrecy’. It is especially confusing because it is often associated with any protocol that does ephemeral DH key agreement, like TLS—even if, as in TLS<1.3 session resumption, the keys capable of decrypting transcripts of past sessions are deliberately kept around for long periods of time. Instead, you should ask: Who has the data, who has the decryption keys, and when can the decryption keys be erased?

Suppose Alice decides she wants to send a message to Bob, and types it into her laptop.

Let's look at the flow of data in email.

  1. Alice's laptop sends the message to Alice's MTA outgoing.oohay.com over the internet, encrypted.
    • The decryption keys between Alice's laptop and Alice's MTA outgoing.oohay.com can be erased after this step, but now outgoing.oohay.com necessarily has a plaintext copy of the message.
  2. outgoing.oohay.com sends the message to Bob's MTA incoming.oogleborg.com over the internet, encrypted.
    • The decryption keys between outgoing.oohay.com and incoming.oogleborg.com can be erased after this step, but now incoming.oogleborg.com necessarily has a plaintext copy of the message.
  3. A couple days later, after Bob gets back from vacation, he logs into his workstation and downloads the message from incoming.oogleborg.com over the internet, encrypted.
    • The decryption keys between Bob's workstation and incoming.oogleborg.com can be erased after this step, but erasing the keys for the TLS sessions doesn't help with the plaintext copies that were left on Oohay and Oogleborg's servers!

If Alice's message is an OpenPGP-encrypted message, then you also need to answer: When does Bob erase all copies of his decryption key? If it's not before Bob's laptop is compromised, then even if Bob has deleted old email messages, an adversary can use Bob's decryption key to decrypt ciphertexts of old email messages.

In contrast, here's the flow in Signal.

  1. Alice's laptop encrypts the message and some ratcheting administrivia using her current key for Bob, and sends it to the Google mothership for distribution.
    • The Google mothership necessarily has a ciphertext copy of the message, and needs no keys.
    • Alice can now turn her ratchet and erase the key that would allow decryption of the ciphertext stored on the Google mothership.
    • After this point, if Alice has followed the protocol, only Bob has the key to decrypt the ciphertext or any way to derive it.
  2. A couple days later, after Bob gets back from vacation, he logs into his workstation and downloads the ciphertext from the Google mothership.
    • If the ratcheting administrivia shows the messages are in order, Bob can now turn his ratchet and erase the key that would allow decryption of the ciphertext stored on the Google mothership. (If the messages were delivered out of order, Bob has to hang onto the decryption key for a little longer.)
    • After this point, if Alice and Bob have followed the protocol, nobody has the key to decrypt the ciphertext or any way to derive it.

If Bob decides to delete old Signal messages (e.g., with ‘disappearing messages’, which are, of course, voluntary requests for the peer to respect, and which it is good etiquette to respect), then future compromise of Bob's workstation still isn't enough to decrypt ciphertexts of old Signal messages.


Could Bob rapidly rotate his OpenPGP encryption key pairs to achieve a similar effect? Yes—if he erases them that's enough to prevent decryption of past ciphertexts. But there's no OpenPGP tooling to do this automatically, and OpenPGP is enough of a pain to deal with without rolling keys over every Thursday that approximately nobody wants to deal with it, and there's certainly nothing in the protocol to automatically roll keys over after every message while also handling reasonable out-of-order delivery.

That's because OpenPGP was—from a modern perspective with the benefit of hindsight—designed as a toy for early '90s crypto nerds to spend all their time reconfiguring their email clients to handle, mashing ‘signature’ and ‘encryption’ together like LEGO bricks, rather than a protocol to facilitate human interaction like Signal with security goals studied in the cryptography literature.

To be fair to the early PGP designers, a good deal of crucial cryptography literature was evolving concurrently with the development of PGP during the '90s—but even when confronted with basic cryptographic problems in the protocol for humans, the designers abdicated responsibility for addressing them in 2001. Despite contemporary literature on exactly how to address it, to this day OpenPGP doesn't support public-key authenticated encryption. OpenPGP didn't even achieve what has for two decades been the cryptographic standard security notion of public-key encryption until 2018 when EFAIL persuaded the OpenPGP world to begrudgingly make the MDC mandatory—a decade and a half after being alerted to problems with the MDC in 2002.

$\endgroup$
  • $\begingroup$ I never knew of Signal's disappearing messages, so thank you. In my experience—which may change now that I know about disappearing messages—the messages I send and receive via Signal are rarely deleted; thus ignoring the fact that mail servers may also contain the e-mails, it appears that the situation is similar in terms of threat: if my device is compromised before I delete my Signal messages, then I'm screwed. $\endgroup$ – basketballfan22 Oct 14 at 5:10
  • $\begingroup$ While I agree that the situation I speak of is very easy to mess up and a much bigger pain, I also accept that e-mail is quite popular and will be for some time. I just wanted to assess the security of it if my conditions are met. $\endgroup$ – basketballfan22 Oct 14 at 5:20
  • $\begingroup$ is there any [article] that confused this term and has a broad impact term? Also, the forward secrecy is only about generating the key so that when the sites are compromised the attacker cannot generate the previous keys. This actually implicitly defines that the sites must delete the keys after usage. $\endgroup$ – kelalaka Oct 14 at 7:49
  • $\begingroup$ While it's typically done, there is no reason for Alice to send the message to/through outgoing.oohay.com. Instead she can send it directly to incoming.oogleborg.com. Even if Alice's computer is blocked from making outgoing smtp connections or even if incoming.oogleborg.com blocks incoming smtp connections from her dynamic IP, she can route the connection through any host not subject to those restrictions, e.g. with ssh -W. $\endgroup$ – R.. Oct 14 at 15:15
  • 2
    $\begingroup$ @R.. My point is not that you can't shoehorn email into a transport medium for an application with the same deletion properties as Signal. My point is that the question becomes much clearer—and the human-meaningful distinctions between email with PGP and Signal as applications become a lot starker!—when you reject the vague term ‘forward secrecy’ and phrase it instead as a question of when things can be meaningfully deleted. $\endgroup$ – Squeamish Ossifrage Oct 14 at 15:28
2
$\begingroup$

It seems to me that the only way to decrypt someone else's e-mail is if the end-point device has been compromised.

There is no end-to-end encryption with the usual email delivery using SMTP. Any MTA on the way from the sender to the recipient can read the mail since the encryption is only done between the MTA (if at all) and not end-to-end between sender and recipient. Also the mail is then stored at the last MTA before the recipient retrieves it using POP3 or IMAP (and in the latter case it usually stays at the server too).

Also neither sender nor recipient have control about this delivery process, i.e. if encryption is used in the first place, which TLS version and kind of key exchange is used (forward secrecy or not), if certificates are properly checked etc.

Signal instead is true end-to-end encryption between sender and recipient.

$\endgroup$
  • $\begingroup$ There are many reasons why Signal is "better", but I was really focusing on just one of the reasons that is often brought up. In the end they suffer from similar issues from afar, it's just the probabilities of the issues differ a lot. Web of trust ≈ verification of safety number, compromised mail server or end device ≈ compromised Signal device, require both parties to manually encrypt every time and use services that rely on TLS based on (EC)DHE ≈ require both parties use the app. I guess for me some of the arguments are much stronger than others; and to me, forward secrecy is not one. $\endgroup$ – basketballfan22 Oct 13 at 21:49
  • $\begingroup$ I should clarify that my use of "≈" is to denote the similarity of the problem and not the probability. $\endgroup$ – basketballfan22 Oct 13 at 21:53
  • $\begingroup$ Sender most certainly does have control over the delivery process. They can deliver direct to recipient's domain's mx, and refuse to do so if starttls is not accepted or certificate presented is not valid. Recipient can also refuse to receive without tls, but cannot control whether sender's message already traveled through adversarial hops, in which case the content was compromised before the recipient even saw it. $\endgroup$ – R.. Oct 14 at 15:20
  • $\begingroup$ @R..: "They can deliver direct to recipient's domain's mx," - most MX will not accept mails from arbitrary IP. They will commonly block consumer lines (DSL, cable...) and if the sender domain has a SPF record they will often allow access only from the declared IP or tag everything else as potential spam. $\endgroup$ – Steffen Ullrich Oct 14 at 16:21
  • $\begingroup$ @R..: "Recipient can also refuse to receive without tls," - recipients have usually no control over the MTA responsible for the domain, i.e. not ...@gmail.com user can pressure Google to only accept their mails by TLS. $\endgroup$ – Steffen Ullrich Oct 14 at 16:22
0
$\begingroup$

It can be, but only if the sender and recipient are both using email in a presently unconventional way. As someone working on tooling for exactly the kind of thing you're asking about, I hope it will become less "unconventional" at some point, but I'm not holding my breath.

Typically, email users send outgoing mail through an outgoing SMTP server operated by their ISP or email provider (or even through a webmail service). When doing so, this server necessarily sees and can record the unencrypted (or, in your case, encrypted only by PGP but without the forward secrecy of TLS) message. This can be avoided by not using an outgoing SMTP server, but instead having your sending process lookup the receiving mail exchanger (MX) for the recipient's domain via DNS, and delivering directly to it.

Unfortunately, the prevalence of email spam over the past 2+ decades led to many ISPs blocking the outgoing SMTP port, except to their own outgoing server (see above), and also led to most domains' MX servers blocking incoming SMTP connections from IP ranges listed by [extortion rackets posing as] anti-spam organizations as belonging to "dialup"/"dynamic"/"residential" internet users. However, you can of course make SMTP connections to the recipient domain's MX just by tunneling through an IP addresss that's not blocked (e.g. a commercial hosting provider), with the TLS endpoint still local to your end and the host you're tunneling through unable to see the plaintext traffic.

Note that there is also a possibility for interception at the recipient's domain's MX, assuming it's operated by a third party. When making the TLS connection to deliver mail to it, it controls the TLS certificate, private key, and has the power to retain any ephemeral keys. However, if the recipient owns the domain and is operating their own receiving server, then no third parties are involved and, if you send directly to their MX (and enforce DNSSEC validation to ensure that you're actually using the right MX), you really do have end-to-end, with forward secrecy, encryption of email, with secrecy properties comparable to Signal.

So in summary, you can construct e2ee with forward secrecy for email, but it requires both heavy attention to getting it right from both the sender and receipient, and requires the receipient have their own domain and control over all the receiving infrastructure.

$\endgroup$
  • $\begingroup$ The OP is explicitly asking about the use of the current way mail delivery is done (i.e. "e-mail sent from one message transfer agent (MTA) to another") and is not asking if the SMTP protocol can be reused in different setups (as proposed by you, i.e. MUA to recipient MTA) to provide forward secrecy. $\endgroup$ – Steffen Ullrich Oct 14 at 19:39
  • $\begingroup$ @SteffenUllrich, I suppose my question can be generalized to the whole notion of "forward secrecy" which Squeamish Ossifrage touches on. It appears to me that if its usage in regards to Signal is similar to the "typical" usage; then "forward secrecy" must expressly not consider end devices since Signal uses a static key to decrypt older messages. Consequently, in an imaginary world where e-mails are never stored on other devices (e.g., MTAs); then even if I use a static GPG key to encrypt the message, it would constitute as "forward secrecy". $\endgroup$ – basketballfan22 Oct 15 at 14:38
  • $\begingroup$ If one requires the key be stored on some hardware token that prevents the key from being extracted—ignoring things like power analysis—and forcing such a key to only exist on it, then so be it. $\endgroup$ – basketballfan22 Oct 15 at 14:39
0
$\begingroup$

You cannot have "forward security" over a saved message - well, you save it in order to read it afterwards. If the legitimate receiver has any means to read it, someone obtaining the receiver's keys can read it as well.

Signal and similar apps deal with the saved messages by simply deleting them after some time. (It's a bit complicated, but the effect is that the message is gone for good.)

It is the communication that you can have "forward security" over. TLS session ends, session keys are gone, because no one needs them anymore. You cannot decrypt the TLS session even if you have the private keys of both parties.

$\endgroup$
  • $\begingroup$ Can one not have a unique encryption key for each message that is saved on the device? While that would lead to a lot of overhead, it seems to me that would fit the typical definition of "forward secrecy" (i.e., a compromised key can only decrypt a single message and nothing before or after). $\endgroup$ – basketballfan22 Oct 15 at 17:41
  • $\begingroup$ You still have the task of saving or regenerating all those keys for future use. The attacker that owns you can just use the same method. $\endgroup$ – fraxinus Oct 16 at 9:34

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.