commit 3f30d1c88cf13794f49f374dfdd6284847ed7779 Author: George Kadianakis <desnac...@riseup.net> Date: Fri Jan 9 13:24:44 2015 +0200
Add a bit more content to the tech report. - Another reason to worry about statistics. - A risk section --- 2015/hidden-service-stats/hidden-service-stats.tex | 39 +++++++++++++++----- 1 file changed, 29 insertions(+), 10 deletions(-) diff --git a/2015/hidden-service-stats/hidden-service-stats.tex b/2015/hidden-service-stats/hidden-service-stats.tex index 20e9dc9..d3ad6c4 100644 --- a/2015/hidden-service-stats/hidden-service-stats.tex +++ b/2015/hidden-service-stats/hidden-service-stats.tex @@ -302,6 +302,15 @@ to enumerate available services. While hiding the existence of a service is not the primary purpose of hidden services, it's a security feature we don't want to give up easily. +\paragraph{Unknown future attacks} + +Special care needs to be taken when designing and collecting +statistics because in anonymity the attacker landscape changes +continuously and attacks that are currently ineffective might become +powerful in the future. Alternatively, in the future attackers might +be able to acquire auxiliary data that can combine with statistics in +such ways that allow attacks that would not have been possible before. + \subsection{Other aspects of gathering statistics} There are certain aspects of any given statistic that should be @@ -491,6 +500,12 @@ See ticket 13466 for details. % We would learn what fraction of clients and what fraction of services run older tor versions (0.2.3.x or older). +\\ +\textbf{Risks:} +% +As tor-0.2.3.x gets less common and only a few hidden services still +use it, an adversary would be able to track their introduction points +by checking which relays still report TAP clients on their statistics. \subsubsection{Time from circuit purpose change to tearing down circuit} \label{subsubsec:time_circ_purpose_change_to_teardown} @@ -551,7 +566,7 @@ This statistic can also be used to analyze what fraction of services is available for a short time only, and what fraction is available most of the time. -\subsubsection{Number of descriptor publish request (3.1.1.)} +\subsubsection{Number of hidden service descriptors seen by directory (3.1.1.)} \label{subsubsec:num_descriptor_publish} \textbf{Details:} @@ -573,14 +588,6 @@ services (botnets, chat protocols, etc.). Also, learning the number of hidden services per directory will help us find bugs in the hash ring code and also understand how loaded directories are. -FWIW, when \verb+rend-spec-ng.txt+ gets implemented, it will be harder for -hidden service directories to learn the number of served services since -the descriptor will be encrypted. -However, directories will still be able to approximate the number of -services by checking the amount of descriptors received per publishing -period. -If this ever becomes a problem we can imagine publishing fake descriptors -to confuse the directories. \\ \textbf{Risks:} % @@ -602,6 +609,17 @@ are published during certain times of day and certain days of the week, which could correlate with daylight hours and/or working days in certain parts of the world. This information could also be correlated with network outages over time to narrow down the location of hidden services. +\\ +\textbf{Notes:} +% +When \verb+rend-spec-ng.txt+ gets implemented, it will be harder for +hidden service directories to learn the number of served services +since the descriptor will be encrypted. +However, directories will still be able to approximate the number of +services by checking the amount of descriptors received per publishing +period. +If this ever becomes a problem we can imagine publishing fake +descriptors \subsubsection{Number of descriptor updates per service (3.1.2.)} \label{subsubsec:num_decriptor_updates} @@ -1555,4 +1573,5 @@ an objective way, ideally using the stated evaluation criteria. \end{itemize} \bibliography{hidden-service-stats} -\end{document} \ No newline at end of file +\end{document} + _______________________________________________ tor-commits mailing list tor-commits@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits