michael at briarproject.org
Wed Jun 18 05:36:26 PDT 2014
-----BEGIN PGP SIGNED MESSAGE-----
On 18/06/14 06:24, Trevor Perrin wrote:
> On Tue, Jun 17, 2014 at 3:57 PM, Brian Warner <warner at lothar.com>
>> 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
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Messaging