[messaging] SURBs

[Brian Warner]

On 6/17/14 10:24 PM, Trevor Perrin wrote:

> I sort of wish someone would build a new generation of mix net without
> SURBs.

> Looking over Mixminion it seems like SURBs add a lot of complexity and
> problems with stale paths that would be nice to avoid.

Very true. I suspect, though, that SURBs are necessary in some
situations. In particular, if you want to survive a global passive
adversary, where Tor isn't enough. You need to go high-latency to break
up the timing correlations, which means you don't get a return path for
free.

With Tor, Alice-the-whistleblower could send her documents to
Bob-the-well-known-journalist, then she can poll his server to collect
his follow-up questions (because there's a real-time return path). I
think SecureDrop works this way.

With a high-latency mix network, the only way to get messages back to
Alice is for her to run/rent her own server (and reveal the contact
details to Bob). That means she has to plan ahead, and now there's a
potentially-traceable relationship between the server and Alice's true
identity. Higher bar and higher risk.

SURBs don't remove the requirement for her to run her own server, but it
does (in theory) prevent Bob from learning its location, which makes
things safer for Alice.

> I guess SURBs could strengthen identity-hiding for recipients and
> mailboxes, if Tor isn't sufficient. But I think of Pond (and Petmail?)
> as "relationship-hiding" systems more than "identity-hiding". And to
> obscure the sender / mailbox relationship, all you need is the forward
> direction of the mix net.

Hm, that's interesting: I think you're arguing (and I'd agree) that most
people who communicate with each other already know each other. Or at
least that we're building systems to support that mode, rather than
less-common use cases.

One less-common use case is when Alice knows who Bob is
(whistleblower->journalist), but Bob only knows Alice as "that person
who sent me that one document". A super-rare use case would be where
neither Alice nor Bob knows about the other person ahead of time: why
would you want to send a message to a stranger? Some kind of
Cryptographers Chat-Roulette? A mutual friend sets you up on a
super-blind date?

By definition, you can't get authenticated/confidential communication
without being able to define "who" the message should be coming from /
seen by. There's gotta be some target, something to bind to. If we
enumerate the possible sources of this target thing, I think we get:

1: you meet somebody in person
2: you get their contact details from a public place (anonymous sender)
3: you got a message from somebody anonymous and want to reply to them
4: introduction by a common friend (both sides could be anonymous)

In case 1, both sides probably know about each other, so the most we can
offer them is to hide their relationship from the outside world. In case
2 (e.g. journalist's address/key is in the phonebook, whistleblower
wants to contact them anonymously), it could additionally be useful to
hide the sender's identity from the recipient. Case 3 is the same
scenario from the journalist's point of view, where you're trying to
bind the new message to the source of the previous message, but they
don't want to reveal their identity, which isn't always possible (needs
Tor+polling, or Hidden Services, or SURBs).

Case 4 is unusual but implies that hiding both sides from each other, as
well as the rest of the world, might be useful. You could even imagine a
hybrid of 2 and 4, where a matchmaking service receives messages from
anonymous-but-reply-capable senders, decides who to pair up, then
provides them both with a channel that lets them communicate directly
but not learn each other's identities until they're ready. OTOH, I
believe there's no way to prove the matchmaker is no longer in the loop,
so maybe case 4 is an illusion.

cheers,
 -Brian