[messaging] Tor Hidden Services in (Cables, SMTorP, Pond)
trevp at trevp.net
Tue Jun 17 13:32:54 PDT 2014
On Mon, Jun 16, 2014 at 6:53 AM, Tom Ritter <tom at ritter.vg> wrote:
> I think you should point out that we're talking about asyncronous
> protocols. Comparing syncronous HS-based chat protocols with
> asyncronous email-like store-and-forward protocols is apples and
We're sort of talking about turning asynchronous, email-like protocols
*into* synchronous protocols. Which I'm skeptical about.
>> So a store-and-forward system with many users sharing the same mailbox
>> server seems better. This is how Pond works
> I thought Pond let/encouraged you to run your own mailbox?
Dunno about "encouraged". The constant traffic pattern between
recipient and mailbox helps obscure the relationship between senders
and recipients. If every recipient had a unique mailbox then that
would be ineffective, and Pond's relationship-hiding would depend only
> And that if
> you don't run your own, the server learns whether or not you are
> retrieving mail you recieve?
Yup. Though in the scheme of things, that seems like a lesser leak?
> Contrasted to Pynchon Gate which works similarly, but 'better' - your
> mailbox does sit aside many others' mailboxes guarenteed, but the
> nodes you connect to to download data from don't learn if you're
> recieving or even checking your mail thanks to PIR. (This gets you
> closer to Alt.Anonymous for the recipient, except the nymserver knows
> if your nym is recieving mail.)
Agreed that's better, if you could find multiple independent parties to run it.
> I was always a bit bemused by people's desire to run
> Mixmaster/Mixminion nodes (mostly Mixmaster) over Tor Hidden Services.
> It always seemed like this absurd bandaid: "Getting MITM-proof
> StartTLS in SMTP servers is hard: Let's just use Hidden Services!"
> But at the same time, I understand why. HS provides some built-in
> features that make them attractive. Just like using TLS gets you
> confidentiality for free, using HS gets you:
> 1 Authenticity (with no CAs!) on the link
> 2 Confidentiality of the link
> 3 Free and Easy NAT Travsersal, allowing anyone to run a server
> (Especially for Country-Wide NAT)
> 4 Some Anonymity for Client
> 5 An attempt at Anonymity for Server
> 6 'Decentralized Prescence' - login.oscar.aol.com doesn't know if a
> server is online, one must poll and reveal the connection attempt, to
> determine prescence
> Choosing Hidden Services as a Transport Layer makes sense, if only for
> #1-3. Getting 4-6 for free is even better. The problem is really if
> people are relying on, or advertising 4-6.
It's going to be hard to communicate that. If you tell people they're
using a fancy Tor feature so they can run a "hidden" thing that
doesn't reveal data to a server, they're not going to think: "oh,
that's analogous to TLS transport encryption". They're going to
think: this is awesome, I'm invisible!
More information about the Messaging