[messaging] SURBs

[Trevor Perrin]

On Wed, Jun 18, 2014 at 11:59 AM, Brian Warner <warner at lothar.com> wrote:
> 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.

Is it a requirement for Alice to run her own mailbox server?  I would
expect Alice to just have an account on some server, and hope that the
mix network + SURBs keep her from being linked with Bob or
de-anonymized.

It's interesting you're not proposing a "nymserver" here, which I
thought was the classic idea (i.e., Alice gives Bob her email address
"pseudonym at nymserver.com", Alice contacts the nymserver over the mix
net to keep it supplied with SURBs, and one of them is used to relay
Bob's message.)

I assume that's because you want to limit nym -> Alice traffic for
security reasons, so it's safer to dole out SURBs in small quantities
to correspondents?


>> 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.

Or at least, it's nice to solve easier problems on the way to harder ones.

Even if the book-keeping and replenishment of SURBs is handled in
parallel with Petmail / Pond delivery tokens, there seems like a lot
else to worry about for "identity-hiding":
 - Crypto complexity of the SURB design
 - Reliability problems since SURBs encode a particular mix-net path
 - How does Alice introduce herself to Bob; a premise of Pond /
Petmail is the introduction step to exchange delivery tokens, so
mailboxes don't have to choose between rejecting traffic from
anonymized senders or getting killed by spam/abuse.  If you can't
limit spam/abuse this way, it's not clear what you replace it with.

In contrast, Pond (and Petmail?) already has strong sender ->
recipient relationship-hiding due to the traffic padding between
recipients and mailboxes.  To strengthen sender -> mailbox
relationship hiding only requires a mix net in the forward direction.


Trevor