[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[freehaven-cvs] Updated to reflect spec changes -- merged for Bram.
Update of /home2/freehaven/cvsroot/doc/pynchon-gate
In directory moria.mit.edu:/tmp/cvs-serv3182
Modified Files:
pynchon.tex
Log Message:
Updated to reflect spec changes -- merged for Bram.
Index: pynchon.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/pynchon-gate/pynchon.tex,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -d -r1.14 -r1.15
--- pynchon.tex 7 Sep 2004 17:19:06 -0000 1.14
+++ pynchon.tex 7 Sep 2004 23:07:19 -0000 1.15
@@ -13,7 +13,7 @@
\title{The Pynchon Gate}
\subtitle{A Secure Method of Pseudonymous Mail Retrieval}
-\author{Len Sassaman\inst{1} \and Bram Cohen\inst{2}}
+\author{Len Sassaman\inst{1} \and Bram Cohen\inst{2} \and Nick Mathewson\inst{3}}
\institute{K. U. Leuven ESAT-COSIC \\
Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, Belgium
@@ -23,6 +23,9 @@
2018 Shattuck Avenue, Suite 124, \\
Berkeley, CA 94704 USA. \\
\email{bram@bitconjurer.org}
+\and
+The Free Haven Project\\
+\email{nickm@freehaven.net}
}
\maketitle
@@ -155,7 +158,7 @@
\subsubsection{Re-encryption mixes.}
-Re-encryption mixes~\cite {universal} aim to improve the reliability of
+Re-encryption mixes~\cite{universal} aim to improve the reliability of
anonymous message systems. Recent work has shown that re-encryption mixes
can be used to facilitate anonymous message replies~\cite
{reusable-channels}. While reusable anonymous return channels in
@@ -242,6 +245,8 @@
may or may not coexist on the same network device or as part of the same
application.
+% XXX Figure 1.
+
\subsection{The Nym Server}
The public-facing side of The Pynchon Gate consists a nym server which
@@ -252,14 +257,25 @@
messages for the nym owners at their specified email addresses.
Nym servers manage email accounts for pseudonyms (\emph{nym accounts}).
-The account creation process establishes a \emph{fixed shared secret}
-shared between the nym server and the nym owner for use in encrypting and
-authenticating control messages related to the nym email address.
-Similarly, the account creation process establishes a \emph{dynamic shared
-secret}, used to encrypt messages to the nym owner. To achieve forward
-secrecy, each time the dynamic shared secret is used it is subsequently
-changed to the hash of its current value.
+For each nym holder (recipient), the nym server stores a \emph{long-term
+public key,} shared between the nym server and the nym owner for use in
+encrypting and authenticating control messages related to the nym email
+address. Similarly, nym server stores a \emph{short-term shared secret}
+associated with each account, used to encrypt messages to the nym owner.
+These keys are created at account creation time. The shared secret can be
+reset by the nym holder after creation.
+
+The shared secret is updated every cycle, such that, if S[i] is the shared
+secret in cycle i, then S[i+1] = H(S[i]|"NEXT CYCLE").
+From each S[i], the nymserver derives a set of sub-secrets for individual
+messages received that cycle. The j'th sub-secret on day i is:
+ SUBKEY(j+1,i) = H(SUBKEY(j,i) | "NEXT SECRET")
+ SUBKEY(0,i) = H(S[i] | "NEXT SECRET")
+
+We use a separate chain of keys for each cycle so that it is easier for a
+user to resynchronize after missing a few cycles.
+
Messages sent from the nym owner to the nym server include a simple MAC to
authenticate them; they are encrypted at the anonymous mail forwarding
system layer. Messages sent from the nym server to the nym owner are
@@ -268,6 +284,8 @@
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] | "USER ID")
+
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 the at some later time obtain the nym's collator
@@ -275,15 +293,30 @@
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
+derive S[i+1], UserID[i], and SUBKEY(0,i), and immediately discard S[i].
+After using each SUBKEY(j,i), the nymserver should calculate SUBKEY(j+1,i)
+and discard SUBKEY(j,i). After each cycle, the nymserver should discard
+the last SUBKEY, and UserID[i].
+
+% XXXX Clean up the above. I lifted this from the spec -- it should be
+% made pretty. --Len.
+
\subsection{The Collator}
Messages for nym owners are passed to the collator component.\footnote{The
collator component typically resides on the same physical server as the
-nym server component.} The collator component organizes all messages into
-a tree structure, with messages sorted by publicly viewable identifiers
-derived from the dynamic shared secrets. Nodes in the tree are organized
-into fixed-size \emph{buckets}. The collator then publishes metadata about
-the tree as a whole in a widely available manner.
+nym server component.} The collator component organizes all previously
+unretrieved messages into a tree structure, with messages sorted by
+publicly viewable identifiers derived from the dynamic shared secrets.
+Nodes in the tree are organized into fixed-size \emph{buckets}. The
+collator then publishes metadata about the tree as a whole in a widely
+available manner.
+
+% XXXX Overflow? Pending messages? ACK and ERR messages? Do we discuss
+% this here, or later, after explaining the system?
\subsection{The Distributor Nodes}
@@ -292,16 +325,15 @@
using a bandwidth-sparing protocol such as BitTorrent~\cite{bittorrent}.}
Distributors append to each bucket the path from that bucket to the hash
tree root. These distributors communicate to the client application using
-the \emph{Pynchon Gate Client Protocol}.
+the \emph{Pynchon Gate PIR Protocol}.
\subsection{The Pynchon Gate Client}
The \emph{Pynchon Gate Client} application resides on the nym owner's
-local computer, and periodically
-retrieves messages from the distributor
-nodes using the Pynchon Gate Client Protocol.
+local computer, and periodically retrieves messages from the distributor
+nodes using the Pynchon Gate PIR Protocol.
-The Pynchon Gate Client Protocol is as follows: The client application
+The Pynchon Gate PIR Protocol is as follows: The client application
sends a random-looking bit field to the distributor. This bit field has a
length equal to the number of buckets. The distributor performs a linear
scan across all buckets, and xors the buckets whose positions have a
@@ -445,6 +477,11 @@
finishing when the next scan returns to that same point. Thus the latency
is exactly the time of one full scan.
+Back et. al discuss similar performance vs. anonymity trade-off issues for
+low-latency anonymity systems, and also conclude that deployability over
+existing network infrastructure with attainable resources must be a design
+consideration for serious anonymity solutions~\cite{back01}.
+
\section{A Note on Usability}
The most popular pseudonym system ever deployed was {\tt
***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs in the body. http://freehaven.net/