[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[minion-cvs] fairly trivial stuff
Update of /home/minion/cvsroot/doc
In directory moria.seul.org:/tmp/cvs-serv17208
Modified Files:
minion-design.tex minion-design.bib
Log Message:
fairly trivial stuff
Index: minion-design.tex
===================================================================
RCS file: /home/minion/cvsroot/doc/minion-design.tex,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -d -r1.36 -r1.37
--- minion-design.tex 7 May 2002 04:52:26 -0000 1.36
+++ minion-design.tex 7 May 2002 06:52:50 -0000 1.37
@@ -240,10 +240,12 @@
next MIX. We describe the behavior of the last MIX in
Section \ref{subsec:delivery-modules}.
-% A bit more detail about waht is contained in the header: -George
+% A bit more detail about what is contained in the header: -George
-Headers addressed to each intermediate mix are encrypted using RSA-OAEP
- \cite{PKCS1} and are of 128 bytes each. They contain a secret addressed
+Headers addressed to each intermediate mix are encrypted using RSA
+%RSA-OAEP \cite{PKCS1}
+% IMO we should use OAEP+. -DH
+and are of 128 bytes each. They contain a secret addressed
to the node that can be used to generate padding and decrypt the rest
of the message. They also contain the address of the next node to
which to message should be forwarded along with its expected signature
@@ -357,7 +359,7 @@
mini-batches.
For example in the limiting case $w = 1$, the network consists of a
-single MIX cascade (this is the situation considered in Section ??
+single MIX cascade (this is the situation considered in Section 7.1
of \cite{babel}).
Let $N$ be the number of nodes in the network. An interesting case
@@ -397,9 +399,9 @@
\subsection{Indistinguishable replies}
\label{subsec:header-swap}
-By making forwards and replies indistinguishable, we prevent an adversary
+By making forward messages and replies indistinguishable, we prevent an adversary
from dividing the message anonymity sets into two classes. In particular,
-if replies are infrequent relative to forwards, an adversary who controls
+if replies are infrequent relative to forward messages, an adversary who controls
some of the MIXes can more easily trace the path of each reply: even
though the batches may be large, the number of replies in each batch
will be quite small.
@@ -430,15 +432,17 @@
to create onions, and receivers must be able to create reply blocks
and unwrap messages received through those reply blocks. Other parties,
such as those receiving forward messages and those sending direct reply
-messages, do not need to run new software.
+messages, do not need to run new software. (For example, the quoting
+performed by ordinary mail software can be used to include the reply
+block in a direct reply; this is sent to a node at the SMTP Reply-To:
+address, which extracts the reply block and constructs a properly
+formatted onion.)
% Do we ever say how to send a reply without software? -Nick
% Nope. We're just bluffing. Is that ok? -RRD
% We're not bluffing. George used to have a way, but we haven't
% mentioned it here. Should we? -Nick
-% The trick is to use the nym servers: you send a normal email to
-% the nym server which takes care of the messsage packaging and
-% injects it in the remailer network. -George
+% We do now. -DH
We divide a message's path into two \emph{legs}, and split the header
into two equal-size subheaders, each corresponding to a single leg.
@@ -653,6 +657,8 @@
% [*]My only reservation is doing key updates without assymetric
% encryption. I need to doublecheck that such an operation is really
% specified in the RFC. -Nick
+% It is: the server can send a HelloRequest or the client a
+% ClientHello at any time. -DH.
% Also, do we want to specify a required level of encryption? It
@@ -742,7 +748,7 @@
% Should we say _why_ it's undesirable to force reply recipients to
% run local nodes? [My answer is (A) that some people (such as human
% rights activists using internet cafes) want to get replies, but
-% don't have persistant net connections, (B) that Mixmaster
+% don't have persistent net connections, (B) that Mixmaster
% supports it, and not doing so would be a step backwards, and (C)
% that there's not much reason not to.] -Nick
%%%%%%
@@ -997,7 +1003,8 @@
launch a DoS attack by flooding the mailbox to exhaust the available
reply blocks and block further messages from getting delivered.
-A more robust design uses a protocol similar to IMAP \cite{IMAP}:
+A more robust design uses a protocol inspired by e-mail retrieval
+protocols such as IMAP or POP \cite{IMAP,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.
@@ -1009,7 +1016,7 @@
% like pop. -RRD
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 mailbox, and the usual techniques (such as
+like flooding a normal IMAP or POP mailbox, and the usual techniques (such as
allowing the user to delete mails at the server or specify which mails to
download and let the others expire) work fine. The user can send a set
of hashes or other indices to the server after successfully receiving
@@ -1142,8 +1149,9 @@
\end{document}
% Style guide:
-% 'MIX'
+% 'MIX', 'MIXes' (as noun)
% 'MIX-net'
+% 'mix', 'mixing' (as verb)
% 'Mixminion'
% 'Mixmaster'
% 'middleman' [Not with a hyphen; the hyphen has been optional
Index: minion-design.bib
===================================================================
RCS file: /home/minion/cvsroot/doc/minion-design.bib,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- minion-design.bib 6 May 2002 04:53:35 -0000 1.6
+++ minion-design.bib 7 May 2002 06:52:50 -0000 1.7
@@ -77,6 +77,15 @@
note = {\url{http://www.rfc-editor.org/rfc/rfc2060.txt}},
}
+@Misc{POP3,
+ author = {J. Myers and M. Rose},
+ title = {Post {O}ffice {P}rotocol --- {V}ersion 3},
+ howpublished = {IETF RFC 1939 (also STD0053)},
+ month = {May},
+ year = {1996},
+ note = {\url{http://www.rfc-editor.org/rfc/rfc1939.txt}},
+}
+
@Misc{onion-routing,
author = {Naval Research Laboratory},
title = {Onion Routing Publications},
@@ -134,7 +143,6 @@
pages = {115--129},
year = 2000,
publisher = {Springer-Verlag},
- note = {\newline \url{http://vip.poly.edu/mehdi/papers/00668973.pdf}},
}
@InProceedings{disad-free-routes,