[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[minion-cvs] Did a few small corections.
Update of /home/minion/cvsroot/doc
In directory moria.seul.org:/tmp/cvs-serv12535
Modified Files:
minion-design.tex
Added Files:
headerDiagram.eps headerDiagram.fig
Log Message:
Did a few small corections.
+ Added a paragraph on link encryption and attacks on links.
+ Added a diagram of the different configuaration of headers,
and their contents
+ Added the notation for anonymous communications:
(A) -> B: M Sender anonymous
A -> (B): M recipient anonymous
(A) -> (B): M bi-directional anonymous channel.
(A)_l also represents a SURB
--- NEW FILE: headerDiagram.eps ---
%!PS-Adobe-2.0 EPSF-2.0
%%Title: headerDiagram.eps
%%Creator: fig2dev Version 3.2 Patchlevel 3c
%%CreationDate: Mon Oct 28 18:52:09 2002
%%For: gd216@rake.cl.cam.ac.uk (George Danezis)
%%BoundingBox: 0 0 533 249
%%Magnification: 1.0000
%%EndComments
/$F2psDict 200 dict def
$F2psDict begin
$F2psDict /mtrx matrix put
/col-1 {0 setgray} bind def
/col0 {0.000 0.000 0.000 srgb} bind def
/col1 {0.000 0.000 1.000 srgb} bind def
/col2 {0.000 1.000 0.000 srgb} bind def
/col3 {0.000 1.000 1.000 srgb} bind def
/col4 {1.000 0.000 0.000 srgb} bind def
/col5 {1.000 0.000 1.000 srgb} bind def
/col6 {1.000 1.000 0.000 srgb} bind def
/col7 {1.000 1.000 1.000 srgb} bind def
/col8 {0.000 0.000 0.560 srgb} bind def
/col9 {0.000 0.000 0.690 srgb} bind def
/col10 {0.000 0.000 0.820 srgb} bind def
/col11 {0.530 0.810 1.000 srgb} bind def
/col12 {0.000 0.560 0.000 srgb} bind def
/col13 {0.000 0.690 0.000 srgb} bind def
/col14 {0.000 0.820 0.000 srgb} bind def
/col15 {0.000 0.560 0.560 srgb} bind def
/col16 {0.000 0.690 0.690 srgb} bind def
/col17 {0.000 0.820 0.820 srgb} bind def
/col18 {0.560 0.000 0.000 srgb} bind def
/col19 {0.690 0.000 0.000 srgb} bind def
/col20 {0.820 0.000 0.000 srgb} bind def
/col21 {0.560 0.000 0.560 srgb} bind def
/col22 {0.690 0.000 0.690 srgb} bind def
/col23 {0.820 0.000 0.820 srgb} bind def
/col24 {0.500 0.190 0.000 srgb} bind def
/col25 {0.630 0.250 0.000 srgb} bind def
/col26 {0.750 0.380 0.000 srgb} bind def
/col27 {1.000 0.500 0.500 srgb} bind def
/col28 {1.000 0.630 0.630 srgb} bind def
/col29 {1.000 0.750 0.750 srgb} bind def
/col30 {1.000 0.880 0.880 srgb} bind def
/col31 {1.000 0.840 0.000 srgb} bind def
end
save
newpath 0 249 moveto 0 0 lineto 533 0 lineto 533 249 lineto closepath clip newpath
-8.0 253.0 translate
1 -1 scale
/cp {closepath} bind def
/ef {eofill} bind def
/gr {grestore} bind def
/gs {gsave} bind def
/sa {save} bind def
/rs {restore} bind def
/l {lineto} bind def
/m {moveto} bind def
/rm {rmoveto} bind def
/n {newpath} bind def
/s {stroke} bind def
/sh {show} bind def
/slc {setlinecap} bind def
/slj {setlinejoin} bind def
/slw {setlinewidth} bind def
/srgb {setrgbcolor} bind def
/rot {rotate} bind def
/sc {scale} bind def
/sd {setdash} bind def
/ff {findfont} bind def
/sf {setfont} bind def
/scf {scalefont} bind def
/sw {stringwidth} bind def
/tr {translate} bind def
/tnt {dup dup currentrgbcolor
4 -2 roll dup 1 exch sub 3 -1 roll mul add
4 -2 roll dup 1 exch sub 3 -1 roll mul add
4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
bind def
/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
4 -2 roll mul srgb} bind def
/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
/$F2psEnd {$F2psEnteredState restore end} def
$F2psBegin
%%Page: 1 1
10 setmiterlimit
0.06000 0.06000 sc
%
% Fig objects follow
%
/Times-Roman ff 180.00 scf sf
4275 750 m
gs 1 -1 sc (First Leg Header) col0 sh gr
/Times-Roman ff 180.00 scf sf
4275 990 m
gs 1 -1 sc (16 sub headers) col0 sh gr
/Times-Roman ff 180.00 scf sf
4275 1230 m
gs 1 -1 sc (2kb size) col0 sh gr
/Times-Roman ff 180.00 scf sf
4275 1500 m
gs 1 -1 sc (Second Leg Header) col0 sh gr
/Times-Roman ff 180.00 scf sf
4275 1740 m
gs 1 -1 sc (16 sub headers) col0 sh gr
/Times-Roman ff 180.00 scf sf
4275 1980 m
gs 1 -1 sc (2kb size) col0 sh gr
/Times-Roman ff 180.00 scf sf
4275 2250 m
gs 1 -1 sc (Payload ) col0 sh gr
/Times-Roman ff 180.00 scf sf
4275 2490 m
gs 1 -1 sc (28kb size) col0 sh gr
% Polyline
7.500 slw
n 150 1350 m 1275 1350 l 1275 2025 l 150 2025 l
cp gs col0 s gr
% Polyline
n 150 2100 m 1275 2100 l 1275 4200 l 150 4200 l
cp gs col0 s gr
% Polyline
n 150 600 m 1275 600 l 1275 1275 l 150 1275 l
cp gs col0 s gr
/Times-Roman ff 180.00 scf sf
225 1725 m
gs 1 -1 sc (Sender Onion) col0 sh gr
/Times-Roman ff 180.00 scf sf
225 975 m
gs 1 -1 sc (Sender Onion) col0 sh gr
/Times-Roman ff 180.00 scf sf
225 2325 m
gs 1 -1 sc (Payload) col0 sh gr
% Polyline
n 1575 600 m 2700 600 l 2700 1275 l 1575 1275 l
cp gs col0 s gr
% Polyline
n 1575 1350 m 2700 1350 l 2700 2025 l 1575 2025 l
cp gs col0 s gr
% Polyline
n 1575 2100 m 2700 2100 l 2700 4200 l 1575 4200 l
cp gs col0 s gr
/Times-Roman ff 180.00 scf sf
1650 1125 m
gs 1 -1 sc (Reply Block) col0 sh gr
/Times-Roman ff 180.00 scf sf
1650 900 m
gs 1 -1 sc (Single Use) col0 sh gr
/Times-Roman ff 180.00 scf sf
1650 1725 m
gs 1 -1 sc (Random Data) col0 sh gr
/Times-Roman ff 180.00 scf sf
1650 2325 m
gs 1 -1 sc (Payload) col0 sh gr
% Polyline
n 3000 600 m 4125 600 l 4125 1275 l 3000 1275 l
cp gs col0 s gr
% Polyline
n 3000 1350 m 4125 1350 l 4125 2025 l 3000 2025 l
cp gs col0 s gr
% Polyline
n 3000 2100 m 4125 2100 l 4125 4200 l 3000 4200 l
cp gs col0 s gr
/Times-Roman ff 180.00 scf sf
3075 1575 m
gs 1 -1 sc (Single Use) col0 sh gr
/Times-Roman ff 180.00 scf sf
3075 1800 m
gs 1 -1 sc (Reply Block) col0 sh gr
/Times-Roman ff 180.00 scf sf
3075 975 m
gs 1 -1 sc (Sender Onion) col0 sh gr
/Times-Roman ff 180.00 scf sf
3075 2325 m
gs 1 -1 sc (Payload) col0 sh gr
% Polyline
n 7875 600 m 9000 600 l 9000 1575 l 7875 1575 l
cp gs col0 s gr
/Times-Roman ff 180.00 scf sf
7950 825 m
gs 1 -1 sc (Version) col0 sh gr
/Times-Roman ff 180.00 scf sf
7950 1065 m
gs 1 -1 sc (Shared Secret) col0 sh gr
/Times-Roman ff 180.00 scf sf
7950 1305 m
gs 1 -1 sc (Digest) col0 sh gr
/Times-Roman ff 180.00 scf sf
7950 1545 m
gs 1 -1 sc (Next Address) col0 sh gr
% Polyline
[60] 0 sd
n 5700 600 m
6150 600 l gs col0 s gr [] 0 sd
% Polyline
[60] 0 sd
n 5700 1275 m
6150 2925 l gs col0 s gr [] 0 sd
% Polyline
n 6225 600 m 7350 600 l 7350 2925 l 6225 2925 l
cp gs col0 s gr
% Polyline
[60] 0 sd
n 7425 600 m
7800 600 l gs col0 s gr [] 0 sd
% Polyline
[60] 0 sd
n 7425 825 m
7800 1575 l gs col0 s gr [] 0 sd
% Polyline
[15 45] 45 sd
n 6225 900 m
6825 900 l gs col0 s gr [] 0 sd
% Polyline
[15 45] 45 sd
n 6225 1050 m
6825 1050 l gs col0 s gr [] 0 sd
% Polyline
[15 45] 45 sd
n 6225 1350 m
6825 1350 l gs col0 s gr [] 0 sd
% Polyline
[15 45] 45 sd
n 6225 1200 m
6825 1200 l gs col0 s gr [] 0 sd
% Polyline
[15 45] 45 sd
n 6225 1500 m
6825 1500 l gs col0 s gr [] 0 sd
% Polyline
[15 45] 45 sd
n 6225 1650 m
6825 1650 l gs col0 s gr [] 0 sd
% Polyline
[15 45] 45 sd
n 6225 1800 m
6825 1800 l gs col0 s gr [] 0 sd
/Times-Roman ff 180.00 scf sf
375 375 m
gs 1 -1 sc (Forward) col0 sh gr
/Times-Roman ff 180.00 scf sf
1650 375 m
gs 1 -1 sc (Direct Reply) col0 sh gr
/Times-Roman ff 180.00 scf sf
3150 225 m
gs 1 -1 sc (Anonymized) col0 sh gr
/Times-Roman ff 180.00 scf sf
3375 450 m
gs 1 -1 sc (Reply) col0 sh gr
/Times-Roman ff 180.00 scf sf
6300 2100 m
gs 1 -1 sc (Up to 16 ) col0 sh gr
/Times-Roman ff 180.00 scf sf
6300 2580 m
gs 1 -1 sc (padded to) col0 sh gr
/Times-Roman ff 180.00 scf sf
6300 2820 m
gs 1 -1 sc (2kb) col0 sh gr
/Times-Roman ff 180.00 scf sf
6300 825 m
gs 1 -1 sc (Subheader) col0 sh gr
/Times-Roman ff 180.00 scf sf
6300 2340 m
gs 1 -1 sc (subheaders) col0 sh gr
/Times-Roman ff 180.00 scf sf
6525 375 m
gs 1 -1 sc (Header) col0 sh gr
/Times-Roman ff 180.00 scf sf
8025 375 m
gs 1 -1 sc (Sub Header) col0 sh gr
$F2psEnd
rs
--- NEW FILE: headerDiagram.fig ---
#FIG 3.2
Landscape
Center
Inches
Letter
100.00
Single
-2
1200 2
6 150 600 5700 4200
6 4275 600 5700 2550
4 0 0 50 0 0 12 0.0000 4 180 1200 4275 750 First Leg Header\001
4 0 0 50 0 0 12 0.0000 4 135 1065 4275 990 16 sub headers\001
4 0 0 50 0 0 12 0.0000 4 135 585 4275 1230 2kb size\001
4 0 0 50 0 0 12 0.0000 4 180 1395 4275 1500 Second Leg Header\001
4 0 0 50 0 0 12 0.0000 4 135 1065 4275 1740 16 sub headers\001
4 0 0 50 0 0 12 0.0000 4 135 585 4275 1980 2kb size\001
4 0 0 50 0 0 12 0.0000 4 180 615 4275 2250 Payload \001
4 0 0 50 0 0 12 0.0000 4 135 675 4275 2490 28kb size\001
-6
6 150 600 1275 4200
6 150 600 1275 4200
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
150 1350 1275 1350 1275 2025 150 2025 150 1350
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
150 2100 1275 2100 1275 4200 150 4200 150 2100
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
150 600 1275 600 1275 1275 150 1275 150 600
4 0 0 50 0 0 12 0.0000 4 135 990 225 1725 Sender Onion\001
4 0 0 50 0 0 12 0.0000 4 135 990 225 975 Sender Onion\001
-6
4 0 0 50 0 0 12 0.0000 4 180 570 225 2325 Payload\001
-6
6 1575 600 2700 4200
6 1575 600 2700 4200
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
1575 600 2700 600 2700 1275 1575 1275 1575 600
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
1575 1350 2700 1350 2700 2025 1575 2025 1575 1350
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
1575 2100 2700 2100 2700 4200 1575 4200 1575 2100
4 0 0 50 0 0 12 0.0000 4 180 885 1650 1125 Reply Block\001
4 0 0 50 0 0 12 0.0000 4 180 780 1650 900 Single Use\001
4 0 0 50 0 0 12 0.0000 4 135 975 1650 1725 Random Data\001
-6
4 0 0 50 0 0 12 0.0000 4 180 570 1650 2325 Payload\001
-6
6 3000 600 4125 4200
6 3000 600 4125 4200
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
3000 600 4125 600 4125 1275 3000 1275 3000 600
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
3000 1350 4125 1350 4125 2025 3000 2025 3000 1350
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
3000 2100 4125 2100 4125 4200 3000 4200 3000 2100
4 0 0 50 0 0 12 0.0000 4 180 780 3075 1575 Single Use\001
4 0 0 50 0 0 12 0.0000 4 180 885 3075 1800 Reply Block\001
4 0 0 50 0 0 12 0.0000 4 135 990 3075 975 Sender Onion\001
-6
4 0 0 50 0 0 12 0.0000 4 180 570 3075 2325 Payload\001
-6
-6
6 7875 600 9000 1575
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
7875 600 9000 600 9000 1575 7875 1575 7875 600
4 0 0 50 0 0 12 0.0000 2 135 570 7950 825 Version\001
4 0 0 50 0 0 12 0.0000 2 135 975 7950 1065 Shared Secret\001
4 0 0 50 0 0 12 0.0000 2 180 465 7950 1305 Digest\001
4 0 0 50 0 0 12 0.0000 2 135 990 7950 1545 Next Address\001
-6
2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
5700 600 6150 600
2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
5700 1275 6150 2925
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
6225 600 7350 600 7350 2925 6225 2925 6225 600
2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
7425 600 7800 600
2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
7425 825 7800 1575
2 1 2 1 0 7 50 0 -1 3.000 0 0 7 0 0 2
6225 900 6825 900
2 1 2 1 0 7 50 0 -1 3.000 0 0 7 0 0 2
6225 1050 6825 1050
2 1 2 1 0 7 50 0 -1 3.000 0 0 7 0 0 2
6225 1350 6825 1350
2 1 2 1 0 7 50 0 -1 3.000 0 0 7 0 0 2
6225 1200 6825 1200
2 1 2 1 0 7 50 0 -1 3.000 0 0 7 0 0 2
6225 1500 6825 1500
2 1 2 1 0 7 50 0 -1 3.000 0 0 7 0 0 2
6225 1650 6825 1650
2 1 2 1 0 7 50 0 -1 3.000 0 0 7 0 0 2
6225 1800 6825 1800
4 0 0 50 0 0 12 0.0000 2 135 615 375 375 Forward\001
4 0 0 50 0 0 12 0.0000 2 180 900 1650 375 Direct Reply\001
4 0 0 50 0 0 12 0.0000 2 180 915 3150 225 Anonymized\001
4 0 0 50 0 0 12 0.0000 2 180 420 3375 450 Reply\001
4 0 0 50 0 0 12 0.0000 2 180 675 6300 2100 Up to 16 \001
4 0 0 50 0 0 12 0.0000 2 180 690 6300 2580 padded to\001
4 0 0 50 0 0 12 0.0000 2 135 270 6300 2820 2kb\001
4 0 0 50 0 0 12 0.0000 2 135 750 6300 825 Subheader\001
4 0 0 50 0 0 12 0.0000 2 135 795 6300 2340 subheaders\001
4 0 0 50 0 0 12 0.0000 2 135 510 6525 375 Header\001
4 0 0 50 0 0 12 0.0000 2 135 840 8025 375 Sub Header\001
Index: minion-design.tex
===================================================================
RCS file: /home/minion/cvsroot/doc/minion-design.tex,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -d -r1.59 -r1.60
--- minion-design.tex 26 Oct 2002 06:03:35 -0000 1.59
+++ minion-design.tex 28 Oct 2002 19:07:10 -0000 1.60
@@ -102,7 +102,10 @@
\item \textbf{Forward anonymity:} Mixmaster uses SMTP (normal mail) for
transport. We use TLS over TCP between remailers; thus we can introduce
link encryption with ephemeral keys to ensure forward anonymity for
-each message.
+each message. Link encryption also makes obsolete many active and
+passive attacks that could have been performed on the communication
+links, and forces attackers to run corrupt nodes to attack the
+system.
% We also provide flexible delivery schemes ---
%rather than just allowing delivery to mail or Usenet, we allow designers
@@ -174,7 +177,7 @@
MIXes (or MIX nodes), each of which is associated with a public
key. Each MIX receives encrypted messages, which are then decrypted,
batched, reordered, and forwarded on without any information
-identifying the sender. Chaum also proved the security of MIXes
+identifying the sender. Chaum demonstrates the security of MIXes
against a \emph{passive adversary} who can eavesdrop on all
communications between MIXes but is unable to observe the reordering
inside each MIX.
@@ -197,7 +200,9 @@
of messages entering that MIX so the only unknown message in the batch
is the target message \cite{mixmaster-attacks,babel}.
MIX cascade research includes real-time MIXes \cite{realtime-mix} and
-web MIXes \cite{web-mix}.
+web MIXes \cite{web-mix}. Even when not under attack cascades will
+provide smaller anonymity sets than networks since the least
+resourceful acts as a traffic bottleneck.
\subsection{Deployed Remailer Systems}
@@ -346,7 +351,11 @@
replies may be very rare relative to forward messages, and thus
much easier to trace, the Mixminion protocol makes reply messages
indistinguishable from forward messages even for the MIX nodes. Thus
-forward and reply messages can share the same anonymity set.
+forward and reply messages can share the same anonymity
+set. Unfortunately reply blocks are fundamentally more dangerous than
+forward secure communications due to the fact that the adversaries have
+in their possession a string that they can force intermediate mixes to
+decrypt until the originator is reached.
\subsection{Tagging attacks}
\label{subsec:tagging-attacks}
@@ -372,13 +381,18 @@
only after several more hops, and so tagging attacks are still possible.
The most straightforward way to prevent tagging attacks is to
-authenticate the whole message at every hop. For forward messages,
+verify the integrity of the whole message at every hop. For forward messages,
then, the padding added to a message must be derived deterministically,
so that it is possible to calculate
authentication tags for the whole message at each hop. But
the situation becomes more complicated when reply messages are
introduced --- the message and the reply block are
-created by different users.
+created by different users. It is therefore impossible for the creator
+of the SURB to include in the header a checksum of a message it they
+do not yeat know. Mixminion uses a hybrid strategy to protect against
+such attacks, by protecting the headers using cryptographic checksums,
+while making sure that the addressing information contained in the
+message is destroyed if the payload is modified by an adversay.
\subsection{Replies}
\label{subsec:replies}
@@ -414,10 +428,12 @@
Mixminion allows Alice to send messages to Bob in one of three ways:
\begin{enumerate}
-\item \textbf{Forward} messages where only Alice remains anonymous.
-\item \textbf{Direct Reply} messages where only Bob remains anonymous.
+\item \textbf{Forward} messages where only Alice remains anonymous
+($(A) \rightarrow B: M$.)
+\item \textbf{Direct Reply} messages where only Bob remains anonymous
+($A \rightarrow (B): M$.)
\item \textbf{Anonymized Reply} messages where Alice \emph{and} Bob
- remain anonymous.
+ remain anonymous ($(A) \rightarrow (B): M$.)
\end{enumerate}
We require parties that benefit from anonymity properties to run dedicated
@@ -431,6 +447,13 @@
address, which extracts the reply block and constructs a properly
formatted onion.)
+\begin{figure}
+\begin{center}
+\resizebox{15cm}{!}{\includegraphics{headerDiagram}}
+\caption{The header configurations for different anonymity functions.}
+\end{center}
+\end{figure}
+
Messages are composed of a header section and a payload. We divide
a message's path into two \emph{legs}, and split the header section
correspondingly into a main header and a secondary header. Each header
@@ -482,7 +505,8 @@
for encryption.
\end{itemize}
-To fulfill the above requirements we use a large-block cipher; that
+To fulfill the above requirements we use a variable length block
+cipher adapted to the length of the payload; that
is, a cipher that acts as a permutation on a block the size of its
input (a header or the payload). Possible candidates
include LIONESS \cite{BEAR-LIONESS} and SPC \cite{SPC}.
@@ -556,11 +580,19 @@
%Nevertheless, this may still allow an adversary to
%break anonymity in some cases.
-We briefly considered introducing \emph{cover-trash} to frustrate
+We briefly considered introducing \emph{cover-trash}, dummy messages
+designed to look like tagged messages, to frustrate
these tagging attacks; but that problem is as complex as the dummy
-traffic problem \cite{langos02}. Instead, we use the decryption-by-hash-of-payload step at the
+traffic problem \cite{langos02}. Instead, we use the
+% decryption-by-hash-of-payload
+``swap'' step at the
crossover point to prevent the attacker from learning information from
-tagging attacks. Specifically, our solution falls into several cases:
+tagging attacks. The second header of the message, that contains the
+path to the final destination of the forward path, is encrypted by the
+sender by the hash of the payload that is to arrive at the mix. The
+mix then needs to perform the decryption and swap the first header for
+the second one.
+Specifically, our solution falls into several cases:
\begin{itemize}
\item Forward messages: if the message is tagged during the first leg,
@@ -600,6 +632,7 @@
anonymized reply paths.
%The protocol doesn't allow a MIX to know its location in the path (other
%than the exit node), or the total length of the route.
+% [WE NEED TO SAY THIS SOMEWHERE SINCE IT IS AN IMPORTANT FEATURE! -GD]
\subsection{Multiple-message tagging attacks}
\label{subsec:multi-tagging}
@@ -720,6 +753,17 @@
they would have to observe all subsequent traffic to be able to update
their key appropriately.
+Additionally link encryption makes active and passive attacks on the
+network links very difficult. Given that mix messages give an
+indication to the mixes about the identity of their successors it is
+hard for an
+adversary to modify messages, inject messages in a node as if they
+were part of the normal communications, or delete messages. It is
+still possible to delay messages, unless an additional
+\emph{heartbeat} signal is included in the SSL tunnel. This forces a
+determined adversary to run nodes or to corrupt nodes in
+order to break the anonymity of mixminion.
+
The encrypted channel offers only limited protection against traffic
analysis. Encrypted links between honest nodes prevent an adversary
from recognizing even his own messages; but without link padding, he
@@ -733,6 +777,11 @@
\subsection{Message types and delivery modules}
\label{subsec:delivery-modules}
+[I think it is important to say what modules get us in comparison to
+normal client side mixminion (which servers can also use). In
+particular, access to some shared key material and plug-in for
+infrastructure critical services. -GD]
+
Once a Mixminion packet reaches the final MIX in its path, it must
either be delivered to its intended recipient, dropped if it is an
intra-network dummy message, or processed further if it is a remixed
@@ -907,7 +956,8 @@
contain any timestamp or expiration information. Each MIX must keep
hashes of the headers of all messages it has processed since the last time
it rotated its key. MIXes should choose key rotation frequency based on
-security goals and on how many hashes they want to store.
+security goals and on how many hashes they want to store, and
+advertise it widely along with their public key information.
Note that this solution does not entirely solve the partitioning problem
--- near the time of a key rotation, the anonymity set of messages will
@@ -1033,7 +1083,14 @@
from single-use reply blocks.
In the first approach, nymservers keep a stock of reply blocks for
-each mailbox, and use a reply block for each incoming message. As long
+each mailbox, and use a reply block for each incoming message.
+
+\[(A) \rightarrow \mathrm{Nym}: \{\mathrm{Register} ,A', V_{A'}, (A)_1 \dots
+(A)_n\}_{S_{A'}}\]
+\[B \rightarrow \mathrm{Nym}: A', M\]
+\[\mathrm{Nym} \rightarrow (A)_i: M\]
+
+As long
as the owner of the pseudonym keeps the nymserver well-stocked, no
messages will be lost. But it is hard for the user to know how many
new reply blocks to send; indeed, under this approach, an attacker can
@@ -1044,7 +1101,14 @@
protocols such as IMAP \cite{IMAP} or POP \cite{POP3}:
messages arrive and queue at the nymserver, and the user periodically
checks the status of his mail and sends a sufficient batch of reply
-blocks so the nymserver can deliver that mail.
+blocks so the nymserver can deliver that mail.
+
+\[(A) \rightarrow \mathrm{Nym}: \{\mathrm{Register} ,A', V_{A'}\}_{S_{A'}}\]
+\[B \rightarrow \mathrm{Nym}: A', M\]
+\[(A) \rightarrow \mathrm{Nym}: \{\mathrm{Query} ,A', (A)_1 \dots
+(A)_n\}_{S_{A'}}\]
+\[\mathrm{Nym} \rightarrow (A)_i: M\]
+
In this case, the nymserver doesn't need to store any reply blocks.
The above flooding attack still works, but now it is exactly
like flooding a normal IMAP or POP mailbox, and the usual techniques (such as