[freehaven-cvs] Edit and hack up the attacks section

[nickm@seul.org (Nick Mathewson)]

Update of /home/freehaven/cvsroot/doc/pynchon-gate
In directory moria.mit.edu:/tmp/cvs-serv23535

Modified Files:
	pynchon.tex 
Log Message:
Edit and hack up the attacks section

Index: pynchon.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/pynchon-gate/pynchon.tex,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -d -r1.53 -r1.54
--- pynchon.tex	18 Sep 2004 02:25:39 -0000	1.53
+++ pynchon.tex	18 Sep 2004 02:40:18 -0000	1.54
@@ -523,35 +523,34 @@
 this paper. Most attacks on pseudonymity systems fall into one of the
 following categories.
 
-\subsection{Legal and hacking attacks.}
+\subsubsection{Legal and hacking attacks.}
 Attackers may attempt to coerce the operators of pseudonymity systems
 through lawsuits or other means, or may attempt to surreptitiously obtain
-information about nym holders. Systems should be designed so that such
-information cannot be obtained.
+information about nym holders.
 
-The Pynchon Gate protects against these attacks by using encryption keys
-for the nym accounts to encrypt incoming messages. Nym holders do not
-communicate directly with the nym server, and the nym server is not
-entrusted with any identifying information for the user. All data in the
-tree structure is deleted from the collator after being passed to the
-distributors. This ensures that the collator has as little information
+We limit these effects of these attacks by greedily encrypting
+encrypt incoming messages and deleting encryption keys.% Nym holders do not
+%communicate directly with the nym server, and the nym server is not
+%entrusted with any identifying information for the user.
+All sensitive data is deleted from the collator the bucket pool is generated,
+ensuring that the collator has as little information
 useful to an attacker as possible, and that collator resource requirements
 are kept low.
 
-Messages sent from the nym server to the nym owner are
-addressed at the collator to an opaque id which remains unchanged for the
-nym. The actual messages include the iteration number of the dynamic key
-in the clear, and the messages for the nym user are encrypted and MAC'd
-using that iteration of the dynamic key:
-$\UserID{}[i] = H(S[i] | \mbox{\tt "USER ID"})$
+%Messages sent from the nym server to the nym owner are
+%addressed at the collator to an opaque ID which remains unchanged for the
+%nym. The actual messages include the iteration number of the dynamic key
+%in the clear, and the messages for the nym user are encrypted and MAC'd
+%using that iteration of the dynamic key:
+%$\UserID{}[i] = H(S[i] | \mbox{\tt "USER ID"})$
 
-Dynamic key rotation allows us to achieve forward secrecy. Without dynamic
+%Dynamic key rotation allows us to achieve forward secrecy.
+Without dynamic
 key rotation it would be trivial for an attacker to archive all data sent
 to distributors, and then at some later time obtain the nym's collator
 address and key from the nym server though an active attack on those
 components. The attacker would then be able to read all messages that nym
 has ever received.
-
 In the interest of retaining little information for an attacker,
 implementations should discard old secrets \emph{as soon as they are no
 longer needed.} Thus, at the start of each cycle i, a nymserver should
@@ -561,9 +560,9 @@
 and discard $\SUBKEY(j,i)$.  After each cycle, the nymserver should discard
 the last $\SUBKEY(j,i)$, and $\UserID{}[i]$.
 
-\subsection{Mix attacks.} 
-Systems based on the mix-net primative must be concerned with attacks
-against the underlying mix-network, as they rely upon it for security.
+\subsubsection{Mix attacks.}
+Since we rely on mix networks, we must be concerned with attacks
+against them.
 Additionally, reply-block-based nym server systems require additional
 security properties that normal mix-net systems may not have~\cite{minx}.
 
@@ -571,29 +570,28 @@
 which do not work against a mix-net in normal forward-delivery mode will
 not impact Pynchon Gate.
 
-\subsection{Man-in-the-middle attacks.}
-An attacker able to pose as a component in the system may be able to learn
-information about the users of the system. Authentication of the
-components should be performed to prevent such attacks.
-
-To prevent man-in-the-middle attacks against the distributors, TLS is used
-as the protocol's transport layer~\cite{rfc-2246}. Users negotiate a TLS
-connection with a given distributor, and then relay PIR messages as
-described. The connection is authenticated using a certificate in a
-two-level certificate chain. The top-level certificate is a self-signed
-long-term certificate for the distributor. The second-level certificate is
-used to authenticate the distributor and establish the TLS session for the
-PIR protocol, and should be rotated regularly to provide forward secrecy.
+\subsubsection{Man-in-the-middle attacks.}
+An attacker able to pose as a user's chosen distributors could trivially
+see all $k$ PIR requests.  We use TLS authentication to prevent this attack.
 
-\subsection{Replay attacks.}
-An attacker capable of monitoring the communications network may attempt
-to obtain information about nym holders by comparing network and user
-behavior when a given message or packet is transmitted multiple times.
+%To prevent man-in-the-middle attacks against the distributors, TLS is used
+%as the protocol's transport layer~\cite{rfc-2246}. Users negotiate a TLS
+%connection with a given distributor, and then relay PIR messages as
+%described. The connection is authenticated using a certificate in a
+%two-level certificate chain. The top-level certificate is a self-signed
+%long-term certificate for the distributor. The second-level certificate is
+%used to authenticate the distributor and establish the TLS session for the
+%PIR protocol, and should be rotated regularly to provide forward secrecy.
 
-The Pynchon Gate uses TLS when communicating between components and the
-client, so that data is encrypted with a short-lived session key. The
-topology of the Pynchon Gate infrastructure further eliminates areas of
-potential replay attack risk.
+%\subsubsection{Replay attacks.}
+%An attacker capable of monitoring the communications network may attempt
+%to obtain information about nym holders by comparing network and user
+%behavior when a given message or packet is transmitted multiple times.
+%
+%The Pynchon Gate uses TLS when communicating between components and the
+%client, so that data is encrypted with a short-lived session key. The
+%topology of the Pynchon Gate infrastructure further eliminates areas of
+%potential replay attack risk.
 
 \subsection{Tagging and known-cleartext attacks.} An attacker may alter
 a message, or observe the cleartext of a message, so that he may be able
@@ -602,51 +600,53 @@
 
 The Pynchon Gate's message and link encryption prevents an attacker from
 observing the cleartext of a message. Tagging attacks are ineffective, as
-the data transfered to the user from the distributors appears random. The
+TLS protects data integrity on the wire. The
 metaindex provides the client with the hash of the index bucket. Each
 message bucket provides the hash of the next message bucket, and with this
 information, the client can verify the integrity of information downloaded
 from distributors and respond to garbled data without leaking information
-about which bucket it was requesting.
+about which bucket it was requesting.\footnote{If a client {\it does} notice
+  a corrupt bucket, it should not re-attempt the PIR operation until it has
+  received all buckets, to avoid leaking which bucket it was reading through
+  the timing of its response.}
 
-\subsection{``{\it Who am I?}'' attack.} 
+\subsubsection{``{\it Who am I?}'' attack.}
 An attacker may send messages intended for nym Alice to nym Bob instead,
-to confirm that Alice and Bob are the same nym holder~\cite{gd-thesis}.
+so that if ``Alice'' responds, the attacker will know they are the same nym
+holder~\cite{gd-thesis}.
 
 This attack relies primarily upon the ability to link one nym, $Alice_1$,
-with another nym, $Alice_2$, by sending a message encrypted with
-$Alice_1$'s reply block to $Alice_2$'s address. The architecture of
-Pynchon by the nature of its design avoids this, though a similar social
+with another nym, $Alice_2$, by sending a message encrypted to
+$Alice_1$'s to $Alice_2$'s address. The
+Pynchon Gate avoids this, though a similar social
 engineering attack may be performed if the nym holder is using a separate
 message encryption protocol such as PGP~\cite{rfc-2440}. More research
 needs to be done in the area of privacy-preserving human-computer
 interaction.
 
-% Also: social engineering; traffic analysis; leave/join attacks...
-
-\subsection{Usage pattern and intersection attacks.}
 
+\subsubsection{Usage pattern and intersection attacks.}
 An attacker may analyze network usage and anonymity set members over time
 to sub-divide anonymity sets such that a given user is identified. In
 addition to passive observation of the network, there are a number of
-active attacks which can facilitate usage pattern attacks. An attacker may
-flood a nym, to observe a corresponding increase in traffic by the
-recipient. If attacks on portions of the pseudonymity infrastructure
-affect some users differently than others, an attacker may exploit such
-attacks on components of the system to facilitate an intersection attack
-against a user of the system as a whole. For instance, in a reply-block
-system, an attacker could disable certain mixes, and observe which nyms
-ceased receiving traffic. If the nym holder has a fixed-route reply block,
-this would enable the attacker to identify the mixes used in the
-nym holder's reply-block path, and increase his chances of successfully
-linking the nym with the nym holder's true name.
+active attacks. For example, an attacker could
+flood a nym to observe a corresponding increase in traffic by the
+recipient.% If attacks on portions of the pseudonymity infrastructure
+%affect some users differently than others, an attacker may exploit such
+%attacks on components of the system to facilitate an intersection attack
+%against a user of the system as a whole.  For instance, in a reply-block
+%system, an attacker could disable certain mixes, and observe which nyms
+%ceased receiving traffic. If the nym holder has a fixed-route reply block,
+%this would enable the attacker to identify the mixes used in the
+%nym holder's reply-block path, and increase his chances of successfully
+%linking the nym with the nym holder's true name.
 
 Users of the Pynchon Gate select distributors from which to receive data
 at random, each time the nym holder retrieves her messages. As opposed to
 systems where the pseudonym infrastructure initiates the delivery of
 messages, the Pynchon Gate Client initiates the retrival of messages, and
 thus message retrieval cannot be correlated to a given nym by a malicious
-sender. 
+sender.
 
 Message buckets are of a fixed size, to protect against attacks similar to
 the active flooding attacks on mix-net systems~\cite {trickle02} as well
@@ -654,26 +654,23 @@
 the system is too great to return in this normalized manner, delivery may
 be conducted by \emph{trickling} the pending messages to the distributors
 over the next several tree distributions. To protect against denial of
-service attacks, a notation must be included in the data from the collator
-indicating that there are further messages waiting as well as the size of
-the pending data to be delivered. The client may then send administrative
-requests via an anonymous email message to the collator indicating whether
-the pending messages should be delivered or discarded.\footnote{If a
+service attacks, users can selectively retrieve or delete excess messages.
+\footnote{If a
 client will be retrieving large amounts of data on a regular basis, this
 method will not work. Instead, the client should at account creation time
 request a sufficient number of buckets to receive all data destined to it.
 Pending data queued on the collator should be expired after a reasonable
 amount of time.}
 
-A hash tree of variable depth would risk leaking usage information about
-nym-holders. The Pynchon Gate uses a tree of a fixed depth.
+%A hash tree of variable depth would risk leaking usage information about
+%nym-holders. The Pynchon Gate uses a tree of a fixed depth.
 
 Since the time between the delivery of a message to the nym server and a
 reply from the nym holder may leak information about the nym holder to an
 observer, traffic from the client to the distributors is regulated by the
-client, which queries the distributors only at given intervals. The
-intervals chosen are random within the message window, to thwart active
-attacks against the distributor targetting a specific client.
+client, which queries the distributors only at given intervals. To thwart active
+attacks against the distributor targetting a specific client, clients should
+choose these intervals randomly.
 %XXXX Fix this in design.
 
 \subsection{Statistical disclosure against reply-block-based nym servers}

***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs       in the body. http://freehaven.net/