[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[minion-cvs] clean up FAQ a bit



Update of /home/minion/cvsroot/doc/website
In directory moria.mit.edu:/tmp/cvs-serv31640/doc/website

Modified Files:
	FAQ.html 
Log Message:
clean up FAQ a bit

Index: FAQ.html
===================================================================
RCS file: /home/minion/cvsroot/doc/website/FAQ.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- FAQ.html	16 Dec 2003 05:07:37 -0000	1.3
+++ FAQ.html	1 Mar 2004 06:38:37 -0000	1.4
@@ -123,7 +123,7 @@
 <div class="answer">
 <p>Back in 1981, David Chaum wrote a
 <a href="http://freehaven.net/anonbib/#chaum-mix";>paper</a>
-describing an anonymity server called a "mix".  In Chaum's design,
+describing an anonymity server called a "mix."  In Chaum's design,
 users encrypt messages to a mix's public key, and send those messages
 to the mix.  The mix delays and re-orders the messages in order to
 prevent an eavesdropper from correlating messages entering and
@@ -137,7 +137,7 @@
 "chain") of mixes.  This way, if even a single mix in the sender's
 chain is honest, that mix prevents an attacker from linking the sender
 to the recipient.  The complete set of intercommunicating mixes is
-called a "mix-net".
+called a "mix-net."
 </p>
 <p>
 The term 'remailer' comes with a more application-oriented pedigree.
@@ -425,6 +425,8 @@
 <h3>What's a SURB?  Why doesn't Type III have multiple-use reply
 blocks?</h3>
 <div class="answer">
+<p>"SURB" stands for "single-use reply block": In Type III, reply blocks
+  can only be used once.</p>
 <p>All multiple-use reply block designs that we're aware of suffer
   from a common problem:  anybody who gets ahold of a MURB can use it
   to send an arbitrary pattern of traffic to the recipient.  An
@@ -444,7 +446,8 @@
 <ul>
   <li>Email has become complicated.  Misconfigured MTAs, spam filters, and
     virus scanners have been known to block or corrupt Type I/II packets as
-    they between and the next.  Such bugs are often hard to diagnose and
+    they travel between one server and the next.
+    Such bugs are often hard to diagnose and
     address, since the offending systems are typically operated by ISPs out
     of the remops' control.  Even when these systems relay Type I/II packets
     correctly, they often keep logs and backups that can help an adversary
@@ -455,7 +458,7 @@
     Postfix/TLS; for authentication, remops must exchange certificates
     manually; and for forward secrecy, they must configure their MTA's TLS
     module to only use forward-secure ciphersuites.  Not all remops have done
-    these steps, especially the ones required for forward secrecy.  (As of
+    these steps.  (As of
     this writing, it seems that roughly half of the Type I/II remailers have
     TLS support, and that roughly three fourths of those are using
     forward-secure cypersuites.)</li>
@@ -631,7 +634,6 @@
   <ul>
     <li>Distributed directories.  (The current centralized directory
       is a single point of failuure.)</li>
-    <li>Support for servers with dynamic IP addresses.</li>
     <li>Automatic generation of dummy messages</li>
     <li>Built-in network reliability testing ("pinging")</li>
   </ul></li>