[messaging] SURBs

Michael Rogers michael at briarproject.org
Wed Jun 18 05:36:26 PDT 2014

Hash: SHA256

On 18/06/14 06:24, Trevor Perrin wrote:
> On Tue, Jun 17, 2014 at 3:57 PM, Brian Warner <warner at lothar.com>
> wrote:
>> Knowing that a SURB had really been spent was non-trivial, though
>> (an intermediate node failure would render the SURB useless for
>> the sender, but wouldn't notify the recipient that it was spent).
>> If someone were to build SURBs into a new generation of mix
>> network, it'd be nice if they automatically expired after some
>> period of time.
> I sort of wish someone would build a new generation of mix net
> without SURBs.
> 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.
> Looking over Mixminion it seems like SURBs add a lot of complexity
> and problems with stale paths that would be nice to avoid.

We absolutely should build a new generation of mix networks, designed
for unlinkability rather than sender anonymity. That would solve the
problem Paul Syverson describes in 'Sleeping Dogs Lie' -  mix networks
theoretically provide strong anonymity, but in practice they've never
attracted enough users to form large anonymity sets, because people
rarely want to send email anonymously.

There is a use case for large-scale uptake of mix networks, but it's
relationship privacy rather than sender anonymity.

Sketch of a remailer network for relationship privacy:
* Alice writes a message to Bob
* Alice knows she and Bob both use TAM, so their mail servers are mixes
* Alice chooses a path through the mix network
* The first mix is Alice's mail server, the last is Bob's mail server
* Alice encrypts the message and submits it to her mail server
* Each mix removes a layer of encryption and mixes the message
* Bob collects the message from his mail server
* Forward-secret TLS on all links
* Optional dummy traffic (client-mix and mix-mix)
* Standard crypto for messages, no exotic large block ciphers etc

This is incrementally deployable: if works even if there are only one
or two mixes.

Version: GnuPG v1.4.12 (GNU/Linux)


More information about the Messaging mailing list