other cleanups that have been sitting in my sandbox

%\newcommand{\workingnote}[1]{(**#1)}   % makes the note visible.

\date{}

\title{Design of a blocking-resistant anonymity system}

\title{Design of a blocking-resistant anonymity system\\DRAFT}

%\author{Roger Dingledine\inst{1} \and Nick Mathewson\inst{1}}

\author{Roger Dingledine \\ The Tor Project \\ arma@torproject.org \and

Here we describe a design that builds upon the current Tor network

to provide an anonymizing network that resists blocking

by government-level attackers.

by government-level attackers. We have implemented and deployed this

design, and talk briefly about early use.

\end{abstract}

  certain strings or patterns in TCP packets.  Offending packets can be

  dropped, or can trigger a response like closing the

  connection.

\item Block a destination by listing its IP address at a

\item Block certain IP addresses or destination ports at a

  firewall or other routing control point.

\item Intercept DNS requests and give bogus responses for certain

  destination hostnames.

We should add a new option ``auto'' that cycles through a set of preferred

ports, testing bindability and reachability for each of them, and only

complains to the user once it's given up on the common options.

complains to the user once it's given up on the common choices.

\subsection{Incentives design}

One approach is a restricted-route topology~\cite{danezis:pet2003}:

predefine which relays can reach which other relays, and communicate

these restrictions to the clients. We would need to compute which links

are acceptable in a way that's decentralized yet scalable, and we would

these restrictions to the relays and the clients. We need to compute

which links are acceptable in a way that's decentralized yet scalable,

and in a way that achieves a small-worlds property; and we

need an efficient (compact) way to characterize the topology information

so all the users could keep up to date.

\subsection{Continue Torbutton improvements}

      especially better docs

\subsection{Vidalia and stability (especially wrt ongoing Windows problems)}

      learn how to get useful crash reports (tracebacks) from Windows users

\subsection{Polipo support on Windows}

\subsection{Auto update for Tor, Vidalia, others}

\subsection{Tor browser bundle for USB and standalone use}

  The major part of hidden services does not require client authorization

  now and won't do so in the future. To the contrary, many clients would

  not want to be (pseudonymously) identifiable by the service (which

  is unavoidable to some extend), but rather use the service

  not want to be (pseudonymously) identifiable by the service (though this

  is unavoidable to some extent), but rather use the service

  anonymously. These services are not addressed by this proposal.

  However, there may be certain services which are intended to be accessed

  previously guaranteed QoS level, thus providing better latency or

  bandwidth for selected clients.

  As a disadvantage of performing authorization within the Tor network can

  be seen that a hidden service cannot make use of authorization data in

  A disadvantage of performing authorization within the Tor network is

  that a hidden service cannot make use of authorization data in

  the transported protocol. Tor hidden services were designed to be

  independent of the transported protocol. Therefore it's only possible to

  either grant or deny access to the whole service, but not to specific

Details:

  1  General infrastructure for authorization to hidden services 

  1. General infrastructure for authorization to hidden services 

  We spotted three possible authorization points in the hidden service

  protocol:

  The general idea of this proposal is to allow service providers to

  restrict access to all of these points to authorized clients only.

  1.1  Client authorization at directory

  1.1. Client authorization at directory

  Since the implementation of proposal 114 it is possible to combine a

  hidden service descriptor with a so-called descriptor cookie. If done so,

  (clients and servers would have to be upgraded anyway for using the new

  features).

  1.2  Client authorization at introduction point

  1.2. Client authorization at introduction point

  The next possible authorization point after downloading and decrypting

  a hidden service descriptor is the introduction point. It is important

  depending on the version of the contained INTRODUCE2 cell; however, this

  approach does not appear very clean.)

  1.3  Client authorization at hidden service

  1.3. Client authorization at hidden service

  The time when a hidden service receives an INTRODUCE2 cell constitutes

  the last possible authorization point during the hidden service

  rendezvous point for 3 times and a total number of 10 connection

  establishments (not requests in the transported protocol) per hour.

  1.4  Summary of authorization data fields

  1.4. Summary of authorization data fields

  In summary, the proposed descriptor format and cell formats provide the

  following fields for carrying authorization data:

  cannot be performed without using an encryption schema for introduction

  information.

  1.5  Managing authorization data at servers and clients

  1.5. Managing authorization data at servers and clients

  In order to provide authorization data at the hidden server and the

  authenticated clients, we propose to use files---either the tor

  and is also a bad idea, because in case of HTTP the requested URL may be

  contained in the Host and Referer fields.

  2  An authorization protocol based on group and user passwords

  2. An authorization protocol based on group and user passwords

  In the following we discuss an authorization protocol for the proposed

  authorization architecture that performs authorization at all three

  derived from the user key will be used for performing authorization at

  the introduction and the hidden service.

  2.1  Client authorization at directory

  2.1. Client authorization at directory

  The server creates groups of users that shall be able to access his

  service. He provides all users of a certain group with the same group key

  server decides to remove authorization for a group, he can simply stop

  publishing hidden service descriptors using the descriptor cookie.

  2.2  Client authorization at introduction point

  2.2. Client authorization at introduction point

  The idea for authenticating at the introduction point is borrowed from

  authorization at the rendezvous point using a rendezvous cookie. A

  number for the encrypted introduction cookies as well as for

  ESTABLISH_INTRO and INTRODUCE1 cells is "1".

  2.3  Client authorization at hidden service

  2.3. Client authorization at hidden service

  Authorization at the hidden service also makes use of the user key,

  because whoever is authorized to pass the introduction point shall be

  connection limit of 10 requests per hour and user that helps prevent some

  threats.

  2.4  Providing authorization data

  2.4. Providing authorization data

  The authorization data that needs to be provided by servers consists of

  a number of group keys, each having a number of user keys assigned. These

  changed, so that they understand the new cell versions and perform

  authorization. But again, the new introduction points would remain

  compatible to the existing hidden service protocol.

/*======================================================================*/

/* Interface to AES code, and counter implementation */

/** Implements an aes counter-mode cipher. */

/** Implements an AES counter-mode cipher. */

struct aes_cnt_cipher {

  /** This next element (howevever it's defined) is the AES key. */

/** This next element (however it's defined) is the AES key. */

#if defined(USE_OPENSSL_EVP)

  EVP_CIPHER_CTX key;

#elif defined(USE_OPENSSL_AES)