On Sun, Jun 29, 2014 at 5:58 PM, Seth David Schoen <sch...@eff.org> wrote: > ... > I wonder if there's a way to retrofit high-latency hidden services > onto Tor -- much as Pond does, but for applications other than Pond's > messaging application.
i know that one mechanism i have used to some limited success is fronting a nginx proxy in front of multiple back-end hidden services as actual sources. this leaves an ephemeral instance (similar to ram only relays) with a different traffic profile more like your average relay. (it has more symmetric bandwidth no matter how lopsided the end point recv vs. xmit is tilted which betrays most direct hidden service serving, or client only links) that is to say: front-onion -> nginx -> 3x-?x many onion HTTP keep-alive with heart-beat if no request in last 30sec it is slower, and less efficient, but also seems to be more robust. (putting multiple onions on the front end to avoid hotspots and transient unavailability another question more apropos availability than unlinkability...) i'd love to see someone do some research on this subject they could make public, hint hint! ;) > For example, maybe there's a way for a hidden service to define an > asynchronous API through which client software can use the service, > and then have some kind of pool of API requests and API replies which > the server can update via asynchronous polling (much as Pond does with > pools of user-to-user messages). this would be quite interesting as a method to pursue further, but also as you mention, still a far cry from strong traffic analysis resistance. (distinct from social graph discovery resistance) best regards, -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk