[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-talk] PrivEx and HS, Re: Tor Weekly News — June 18th, 2014 -

On 14-06-18 07:04 AM, Lunar wrote:
> Collecting statistics from Tor exits in a privacy-sensitive manner
> ------------------------------------------------------------------
> Optimizing the Tor network to better support the most common use-cases
> could make a real difference to its perceived usability. Unfortunately,
> Tor is an anonymity network. Understanding what the most common
> use-cases are, in a way that does not endanger its users, is far from
> being a trivial problem.
> There have been some cases of inconsiderate spying on Tor network users
> in the past [4]. This is one of the motivations for the Tor Project to
> provide and research properly anonymized statistics through the
> Metrics [5] and CollecTor [6] portals.
> Tariq Elahi, George Danezis, and Ian Goldberg are working on new
> solutions to tackle the problem of collecting statistics from Tor exits
> in a privacy-sensitive manner. Tariq announced [7] the PrivEx system,
> which “preserves the security and privacy properties of anonymous
> communication networks, even in the face of adversaries that can
> compromise data collection nodes or coerce operators to reveal
> cryptographic secrets and keys”.
> The introduction of the detailed tech report [8] gives a general
> description of the solution: “PrivEx collects aggregated statistics to
> provide insights about user behaviour trends by recording aggregate
> usage of the anonymity network. To further reduce the risk of
> inadvertent disclosures, it collects only information about destinations
> that appear in a list of known censored websites. The aggregate
> statistics are themselves collected and collated in a privacy-friendly
> manner using secure multiparty computation primitives, enhanced and
> tuned to resist a variety of compulsion attacks and compromises.
> Finally, the granularity of the statistics is reduced […] to foil
> correlation attacks.”
> PrivEx’s threat model is described in section 3, and matches the current
> mode of operation of the Tor network, relying on a set of mostly honest
> collectors while being able to cope with a limited number of malicious
> nodes. Two variants are described: one “is secure in the
> honest-but-curious setting but can be disrupted by a misbehaving actor”
> while “the other is secure in the covert adversary setting in that
> misbehaving servers can be identified”, but is more computationally
> expensive.
> Tariq mentions that implementations of the two variants of PrivEx
> described in the tech report have been created and should soon be
> released to the community. The researchers expect to “start by rolling
> out our own PrivEx-enabled exits in the Tor network and begin collecting
> destination visit statistics” around the “June-August timeframe”.
> Section 6 contains an analysis of the overhead in both CPU and bandwidth
> of the two PrivEx variants, and the requirements seem reasonable.
> Given how much privacy matters to the Tor community and to all network
> users, the researchers wants “a measure of confidence that collecting
> data with PrivEx is inherently good and is being done in a responsible
> and intelligent manner”. They are therefore asking the “community at
> large” to review the design of the proposal, and its implementation once
> released.
> If no fundamental flaws are discovered in the process, the Tor community
> might finally be able to enjoy better network statistics in the
> not-too-distant future.
>   [4]: http://www.ifca.ai/pub/fc11/wecsr11/soghoian.pdf
>   [5]: https://metrics.torproject.org/
>   [6]: https://collector.torproject.org/
>   [7]: https://lists.torproject.org/pipermail/tor-dev/2014-June/006999.html
>   [8]: http://cacr.uwaterloo.ca/techreports/2014/cacr2014-08.pdf

If one wanted to collect statistics on Hidden Service usage as well,
which nodes could be instrumented?  (Requests for .onions don't go via
Exit nodes.  Https://www.torproject.org/docs/hidden-services.html.en )

Perhaps the Introduction Point node - whenever there is a request for a
rendezvous, it could increment a counter for that HS (aka destination
address).  Unlike the Rendezvous Point it wouldnt have the ability to be
corrupted into leaking any other data about the connection such as
timing and volume.

Attachment: signature.asc
Description: OpenPGP digital signature

tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to