On Wed, Jun 18, 2014 at 11:59 AM, Brian Warner <[email protected]> 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 "[email protected]", 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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
