5

The web of trust is a graph where the vertices are GPG users (actually, their keys) and the edges are cross-signatures. If we put issues of owner trust aside and assume that all participants only sign after checking the key fingerprints, I can trust a key that has a path between me and the key in the web of trust graph.

If I write an email to someone in the web of trust, I can therefore encrypt the message and keep the content of the email private. I can't hide the metadata of the mail, though: An eavesdropper will still find out when I sent a mail and to whom. Metadata tells a lot about people, and there have been astonishing (not to say, frightening) achievements of guessing people's gender, sexual orientation, income, etc. to a high probability with telephone metadata. (I don't know whether studies have been done with email metadata, but I'd expect similar results)

The question is: How can we hide metadata even in client-encrypted emails?

I propose the following protocol on top of GPG, inspired by Tor:

  1. I want to send an email to Charlie.
  2. I look for a path through the web of trust from me to him, of minimum length, say, 3. Let's assume it goes through Alice and Bob.
  3. Now the multiple encryption step:
    • I encrypt the mail with Charlie's key.
    • Then I encrypt the already encrypted mail and Charlie's address with Bob's key.
    • Then I encrypt all that and Bob's address with Alice's key.
  4. The sending unwraps everything in the opposite order:
    • I send all I got from the last encryption step to Alice.
    • Alice decrypts, sees Bob's address and sends everything she decrypted to Bob.
    • Bob decrypts once more and sends everything to Charlie.
  5. Finally, Charlie decrypts for the last time.

If I haven't got anything wrong, this has the following properties:

  • Only me and Charlie know the contents of the mail.
  • Only me, Charlie and Bob know the final recipient of the mail.
  • Only me, Charlie and Alice know the sender of the mail.

Is this working? Is it viable? Why don't we send emails that way?

A few possible downsides might be:

  • Someone in the chain might not be online. It might then be clever to send the message along multiple paths.
  • Network traffic increases. If an eavesdropper carefully analyses every sent email from me, Alice, Bob and Charlie, they might notice that Alice sends an email to Bob shortly after I write to her, and so on, tracing the mail to Charlie. How much more resources does this need? Is delaying the emails by a short time (say a few minutes) an effective and acceptable countermeasure?
  • 3
    Why not just encrypt your message to Charlie with his public key, and email it while connected to Tor? – RoraΖ Oct 13 '14 at 16:30
  • The nodes and vertices of a graph are the same thing. Presumably edges are cross-signatures instead? – cpast Oct 13 '14 at 18:31
  • 1
    @raz Wouldn't help against, say, an unscrupulous email provider. Email is not typically sent directly from user A to user B; it's more normal for it to be sent from user A to email server Alpha to email server Beta to user B; as far as I can tell, in this scheme the forwarding would be done on the user end (not the mail server end), so email server Gamma in this scheme would know that Charlie got an email from Bob, but not that the contents decrypt to reveal a message from Turion. – cpast Oct 13 '14 at 18:36
  • 1
    @Turion: Why let Alice or Bob know the ultimate sender/recipient? It seems like it shouldn't be hard to make it so that Alice doesn't know that I'm not just the middle link in a chain, and Bob doesn't know that Charlie isn't just forwarding it on to someone else. All Bob should see is something saying "send this to Charlie" and an encrypted message; he shouldn't know that the message isn't just "send this to David" and another encrypted message. Likewise, Alice shouldn't know that I'm not just passing this on from Evan. – cpast Oct 13 '14 at 18:43
  • @cpast I feel like a Tor hidden service that was an email server would provide the same service. – RoraΖ Oct 13 '14 at 18:48
1

The obvious problem with this is that there is no reason why someone would be willing to act as a mail forwarder just because they are in the PGP web of trust. I have a well connected key and don't plan on becoming your e-mail provider.

Sending messages via Tor, as suggested in the comments, is also unlikely to work as Tor exit nodes are highly likely to be blocked as an anti-spam measure and most exit nodes won't include port 25 in their exit policy anyway.

What you are suggesting, with the minor change that particpants have to opt into being forwarders, is essentially the Mixmaster network. The list of remailers isn't very long but nothing stops you joining the network.

Mixmaster software

0

In order to provide a service like (and actually have it be commercially used) there needs to be participation between multiple parties. The only way I can see this working is if there is a centralized key server that would act as the "Bob" and "Alice" of the equation. If you want to secure yourself from metadata revealing location and any forensic pattern building techniques used to build a profile on you, then you should stick to anonymizing your location. Whether it be through Tor, a VPN service, or I2P.

How far you go all depends on the level of security you deem necessary. If you're a possible target of a 3 letter agency or similar then I would stick to counter surveillance techniques such as security through obscurity, and disinformation; i.e. portraying personality traits and behaviors that cause their psychological profile to be completely off and incorrect to yours.

  • Instead of a centralized key server we could also have a distributed directory of keys, using a protocol like BitTorreent. – Turion Dec 16 '14 at 16:19
  • 2
    -1 You realize that security through obscurity is a negative thing, right? It's not good to use it in trivial situations, and it's certainly not good to use it when you're targeted by a TLA. – forest Dec 10 '17 at 8:36

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.