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 oranges.
> Traffic correlation between sender and receiver is easier than it > would be in a store-and-forward system. I think this is only true if you assume a network observer has limited time-based observability, the lack of desire to do any correlation, and the store-and-forward system performs no mixing. > 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? And that if you don't run your own, the server learns whether or not you are retrieving mail you recieve? 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.) 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 Taking Hidden Services at their face, as a protocol with properties just like TLS is a protocol with properties, Hidden Services is better than TLS, and its failure mode is no worse. > For unlinkability of users with each other, the correlation of packet > timing and sizes between sender and recipient needs to be broken. In > Pond, clients retrieve padded data from their mailbox server at a > roughly constant rate. Hidden Services don't help with this. Exactly. The strongest padding must be done at the application layer, not the Transport Layer. The transport layer can't know (absent an API and storng coupling) what padding should look like for a given application. (My attempts to get TLS 1.3 to support padding notwithstanding.) 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 sounds like Bjarni and SMTorP has their head in the right place with regards to those. -tom PS A somewhat related tangent is that with 'Web 2.0' (or are we at 3.0 yet?) web 'clients' are essentially servers for as long as the tab is kept open. And the real-time updates provided by Facebook/Gmail/etc (even Github I think...) encourage people to keep their tabs open. (Never mind IRC and IMAP Mail Clients.) You, as a person with knowledge of a target's online social media accounts/email address, can cause arbitrary amounts of data to be pushed at _clients_ in many situations now also. _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
