[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[minion-cvs] Update FAQ; add a few new entries
Update of /home/minion/cvsroot/doc/website
In directory moria.mit.edu:/tmp/cvs-serv15332/website
Modified Files:
FAQ.html
Log Message:
Update FAQ; add a few new entries
Index: FAQ.html
===================================================================
RCS file: /home/minion/cvsroot/doc/website/FAQ.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- FAQ.html 4 Sep 2003 20:03:02 -0000 1.2
+++ FAQ.html 16 Dec 2003 05:07:37 -0000 1.3
@@ -14,7 +14,7 @@
</head>
<body>
-<h1>
+<h1>
Mixminion/Type III Remailer FAQ
</h1>
@@ -33,7 +33,7 @@
entries are by me unless otherwise noted.
</p>
-<!--
+<!--
<h4>Contents</h4>
<ul>
<li>1. General
@@ -45,7 +45,7 @@
Back up—what's a remailer? A mix-net?</a><li>
<li><a href="#1-3">1.3.</a>
So how does Type III improve
-
+
</ul></li>
<li>2. Design</li>
<li>3. Implementation</li>
@@ -58,7 +58,7 @@
</h2>
<h3>
-<a name="whats-mixminion">Mixminion?</a>
+<a name="whats-mixminion">Mixminion?</a>
Type III? What are you talking about?
</h3>
<div class="answer">
@@ -74,17 +74,17 @@
implementation of the protocol. (The protocol used to be named
"Mixminion" too, but when the Mixmaster team
<a href="http://archives.seul.org/mixminion/dev/Apr-2002/msg00045.html";>
-decided</a> to use support "Mixminion" protocol as the basis for
+decided</a> to use the "Mixminion" protocol as the basis for
Mixmaster version 4, we changed the name of the protocol to be more
project neutral.)
</p>
</div>
<h3>
-What exactly do you mean by
+What exactly do you mean by
<a name="whats-anonymous">"anonymous"</a>?
</h3>
-<div class="answer">
+<div class="answer"><!-- Use the word 'untraceability'. XXXX -->
<p>
When you communicate on the Internet, even when you use encryption,
anybody receiving or intercepting your communication can tell which
@@ -116,12 +116,12 @@
</div>
<h3>
-Back up—what's a remailer?
+Back up—what's a remailer?
<a name="whats-a-mix-net">A mix-net</a>?
</h3>
<div class="answer">
-<p>Back in 1981, David Chaum wrote a
+<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,
users encrypt messages to a mix's public key, and send those messages
@@ -143,7 +143,7 @@
The term 'remailer' comes with a more application-oriented pedigree.
It originally referred to anonymity servers that accepted messages
via email and delivered them via email, without necessarily
-supporting decryption, batching, or chaining. Later generations of
+supporting encryption, batching, or chaining. Later generations of
remailer added these features, and thus have become true mixes.
</p>
<p>
@@ -158,7 +158,7 @@
</div>
<h3>
-In theory, <a name="how-anonymous">how much anonymity</a>
+In theory, <a name="how-anonymous">how much anonymity</a>
does Type III give me?
</h3>
<div class="answer">
@@ -190,7 +190,7 @@
</div>
<h3>
-So how does Type III improve on other
+So how does Type III improve on other
<a name="how-improve-deployed-mix">deployed</a>
remailer designs?
</h3>
@@ -206,7 +206,7 @@
added new features in an attempt to mitigate some of the protocol's
weaknesses, with limited success. Lance Cottrell's Type II (1995)
software fixed most of Type I's insecurities, but dropped
- support for reply blocks.
+ support for reply blocks.
</p>
<p>The following table outlines the feature-differences and security
differences between the three protocols. Parenthesis indicate
@@ -293,10 +293,11 @@
<p>XXX What else?</p>
<h6>Notes</h6>
<dl>
-<dt>a.</dt><dd>Some type I implementations support a XXX directive to
- limit the number of times a given message can be replayed. Using
- this directive is optional, however, and users of this directive
- are distinguishable from non-users.</dd>
+<dt>a.</dt><dd>Some type I implementations support a XXX directive to limit
+ the number of times a given message can be replayed. Using this
+ directive is optional, however, and users of this directive are
+ distinguishable from non-users. It does not solve reply-block flooding
+ attacks.</dd>
<dt>b.</dt><dd>Some type I implementations support message padding in
an attempt to prevent an attacker from correlating messages based
on their size. This feature is of little or no security benefit,
@@ -322,7 +323,7 @@
</div>
<h3>
-And how is Type III different from other
+And how is Type III different from other
<a name="how-improve-deployed-other">deployed</a> anonymity systems?
</h3>
<div class="answer">
@@ -353,7 +354,7 @@
"theoretical" because they are better known through the research
literature than via any widely deployed implementation.)
</p>
-<p>Gülcü and Tsudik's
+<p>Gülcü and Tsudik's
<a href="http://freehaven.net/anonbib/#babel";>Babel</a> mix design
(1996) addresses Type I's size-correlation and PGP issues, while
adding multiple-use reply blocks. Unlike Babel, Type III's reply
@@ -389,14 +390,14 @@
and <a href="http://mixminion.net/dir-spec.txt";>dir-spec.txt</a>
for information about server descriptors and directory
capabilities.</li>
-<li>The specifications are not yet finalized. See
+<li>The specifications are not yet finalized. See
<a href="http://mixminion.net/spec-issues.txt";>spec-issues.txt</a>
- for a list of open issues. There's also a
+ for a list of open issues. There's also a
<a href="http://mixminion.net/spec-issues.txt";>draft design for
directory agreement</a>, and a
<a href="http://mixminion.net/nym-spec.txt";>draft nymserver
specification.</a></li>
-<li>If you want to learn more about anonymity, see
+<li>If you want to learn more about anonymity, see
the <a href="http://freehaven.net/anonbib";>Freehaven.net anonymity
bibliography</a>.</li>
</ul>
@@ -428,19 +429,129 @@
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
eavesdropper or compromised exit remailer can use this property to
- trace a MURB's recipients. (Some MURB designs have additional
- vulnerabilities to replay attacks and flooding attacks.)
-</p>
-<p>XXXX write more.
-</p>
+ trace a MURB's recipients with end-to-end traffic analysis.</p>
+<p>Some MURB designs (such as Type I) have additional
+ vulnerabilities to replay attacks and flooding attacks.</p>
</div>
-<h3>Why doesn't Type III have (insert feature here)?</h3>
+<h3>Why don't you just use SMTP with TLS for mix-to-mix transfer?</h3>
<div class="answer">
+<p>Older remailer designs use SMTP not only for delivering messages to their
+ recipients, but also for transferring packets from one remailer to the
+ next. Type III, however, uses MMTP (a simple TLS-based protocol) when
+ transferring packets to or from remailers. This has several advantages,
+ including:</p>
+<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
+ 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
+ analyze the mix network.</li>
+ <li>MMTP is always encrypted, authenticated, and forward-secure. SMTP is
+ not necessarily so. For SMTP to be encrypted, Type I/II remailer
+ operators need to install and configure a TLS-capable MTA such as
+ 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
+ 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>
+ <li>Because Type III remailers use MMTP, they are free to set their own
+ policies for access control, for retrying failed deliveries, and so on,
+ independently of their policies for mail delivery.</li>
+ <li>Because email is not always 8-bit clean, packets must be encoded
+ before transmitting them as email messages. This adds a non-negligible
+ (typically about 35%) bandwidth overhead.</li>
+</ul>
+<p>There are, however, a few drawbacks to not using SMTP for relaying
+ messages. We believe that they are outweighed by the benefits of a
+ uniform, integrated, encrypted protocol, but we list them for completeness:
+ </p>
+<ul>
+ <li>Some people have argued that using encrypted SMTP helps remailer
+ traffic blend in with non-remailer traffic, if a remailer's MTA also
+ handles regular email. This is probably of less benefit than it might
+ seem at first: since type III packets are fixed-size, an attacker can
+ probably distinguish them from regular email by size, even if encryption
+ is used.</li>
+ <li>MMTP adds complexity to every Type III client and server; if we just
+ used SMTP, our code would be simpler and smaller. (Currently, the MMTP
+ implementation and the store-and-forward together take about 9% of the
+ Mixminion codebase.)</li>
+</ul>
</div>
-<h3>Why don't you just use SMTP with TLS for mix-to-mix transfer?</h3>
+<h3>Why do you use AES128 and SHA1? Ferguson and Schneier's <i>Practical
+ Cryptography</i> says...</h3>
+<div class="answer">
+<p>The relevant quote (from p. 65) is:
+<blockquote>A 128-bit key would be great except for one problem: collision
+ attacks. Time and time again we find systems that can be attacked by a
+ birthday attack or a meet-in-the-middle attack. We know these attacks
+ exist. Sometimes designers just ignore them, and sometimes they think
+ they are safe but somebody finds a new, clever way of using them. Most
+ block cipher modes allow meet-in-the-middle attacks of some form. We've
+ had enough of this race, so here is one of our design rules.
+ <br><br>
+ <b>Design rule 3.</b> <i>For a security level of n bits, every
+ cryptographic value should be at least 2n bits long.</i></blockquote>
+<p>Because of this principle, Ferguson and Schneier recommend AES-256 as a
+ block cipher and double-SHA-256 as a digest function. The current type III
+ specification, on the other hand, calls for 128-bit AES and 160-bit SHA1:
+ if there were a way to exploit birthday or meet-in-the-middle attacks against
+ our protocol, then instead of 128 bits of security, we would only have 64
+ or 80.</p>
+<p>(Collision attacks exploit the property that "If an element can take on
+ N different values, then you can expect the first collision after choosing
+ about SQRT(N) random elements." Thus, one only needs to perform about 2^80
+ SHA-1 operations to find two different strings that hash to the same
+ value.)</p>
+<p><em>We do not now believe</em> that there are any useful collision
+ attacks against the Type III protocol. Here's why:</p>
+<p>First, we can exclude attacks where an attacker waits for collisions in
+ AES128 keys or SHA1 digests: to do so, the attacker would need at least
+ 37 zettabytes (!) of storage to store just a single-leg 2K header for
+ each message. Thus, the attacker's best hope is to find collisions
+ on their own and then somehow exploit them. But even if an attacker does
+ know a set of collisions, they could at worst use them to send packets of
+ their own which would interfere with each other, not to compromise
+ others' anonymity.</p>
+<p>F&S also recommend double-SHA (that is, SHA(SHA(x))) as a digest
+ algorithm, since SHA has the regrettable property that SHA(x|y) can be
+ deduced from SHA(x) and y. We use variable-length SHA in 6 places, all of
+ which we believe to be safe:</p>
+<ol>
+ <li>The OAEP padding we use with RSA uses plain SHA—but OAEP has
+ been well analyzed by many people, and is believed to be safe.</li>
+ <li>The SSL ciphersuites we recommend use plain SHA—but again,
+ SSL is well-analyzed, and it is believed to use SHA safely.</li>
+ <li>In MMTP and in end-to-end message encoding, we send each "msg" along
+ with SHA(msg) to check
+ whether the message has been corrupted—but in these cases, we are
+ only concerned with accidental corruption, and have other approaches to
+ prevent deliberate modification.</li>
+ <li>Our keystore implementation uses SHA(salt|password|salt) as an
+ AES key to encrypt the actual stored secret keys on the disk. But this
+ value is secret (since the password is secret), so the SHA vulnerability
+ has no application.</li>
+ <li>The LIONESS variable-length block cipher uses SHA as part of its
+ Feistel-like structure. But again, the SHA-extending attack doesn't
+ allow an attacker to break LIONESS.
+ <li>Directories and server descriptors sign SHA digests. But in this
+ case there is no problem with the attacker computing a digest for a
+ longer descriptor/directory, so long as he can't forge an RSA
+ signature.</li>
+</ol>
+<p>So there doesn't seem to be any need to move to AES-256 and double-SHA-256
+ right now.</p>
+</div>
+
+<h3>Why doesn't Type III have (insert feature here)?</h3>
<div class="answer">
+<p>(XXXX list a bunch of features.)
</div>
<h3>Is the design paper still accurate? What's changed since
@@ -448,14 +559,13 @@
<div class="answer">
<p>Changes since the publication of the original design paper are:</p>
<ul>
- <li>We no longer perform key rotation on MMTP connections. MMTP
+ <li>We no longer perform session key rotation on MMTP connections. MMTP
connections are typically so short-lived that it doesn't impose
any significant overhead to close and re-open any connections that
stay open for a long time.</li>
<li>The RSA key length has increased from 1024 bits to 2048 bits,
which led us to change the way we pack subheaders into
headers.</li>
- <li></li>
</ul>
<p>Features in the specification not described in the original design
paper are:</p>
@@ -470,8 +580,8 @@
<ul>
<li>Incoming email gateways.</li>
<li>Automatic opt-out.</li>
- <li>Coordination between multiple directories. (But see
- <a href="http://mixminion.net/dir-agreement.txt";>dir-agreement.txt</a>.)
+ <li>Coordination between multiple directories. (But see
+ <a href="http://mixminion.net/dir-agreement.txt";>dir-agreement.txt</a>.)
</li>
<li>Nymservers. (But see
<a href="http://mixminion.net/nym-spec.txt";>nym-spec.txt</a>.)</li>
@@ -484,7 +594,7 @@
<h3>Where's the code? Does it work?</h3>
<div class="answer">
-<p>You can always find a link to the latest release of the code at
+<p>You can always find a link to the latest release of the code at
<a href="http://mixminion.net/";>http://mixminion.net/</a>.</p>
<p>If you want to access the CVS repository, there's a regularly
updated sandbox with anonymous pserver access. To use it, run:
@@ -493,8 +603,8 @@
<li>cvs -d :pserver:guest@cvs.seul.org:/home/minion/cvsroot login</li>
<li>cvs -d :pserver:guest@cvs.seul.org:/home/minion/cvsroot co src doc</li>
</ul>
-<p>So far as we know, the code works fine. As of 4 September 2003,
- there are 21 servers running, including 11 with exit support.</p>
+<p>So far as we know, the code works fine. As of 15 December 2003,
+ there are 27 servers running, including 11 with exit support.</p>
</div>
<h3>Can I use Mixminion to send anonymous messages today?</h3>
@@ -535,7 +645,8 @@
<h3>What do I need in order to run a Mixminion client?</h3>
<div class="answer">
-<p>Right now, the requirements to build and run a Mixminion client are:</p>
+<p>Right now, the requirements to build and run a Mixminion client on a
+ Unix-like operating system are:</p>
<ul>
<li>A Unix-like operating system. Mixminion is known to work on
Linux, FreeBSD, Macintosh OS X, and Cygwin. It is <em>believed</em> to run
@@ -543,12 +654,12 @@
on those platforms. If you find any bugs, please let us know so
that we can fix them.</li>
<li>A working version of Python. Currently, all Python versions
- since 2.0 are supported. As of 4 September 2003, the stable
- versions of Python are: 2.0.1, 2.1.3, 2.2.3, and 2.3.<p>
+ since 2.0 are supported. As of 15 December 2003, the stable
+ versions of Python are: 2.0.1, 2.1.3, 2.2.3, and 2.3.2.<p>
If you're using Solaris, be aware that some versions of Solaris
come installed with mis-compiled versions of Python that don't have
networking support. Don't worry—compiling your own Python
- installation is dead easy. Go to
+ installation is dead easy. Go to
<a href="http://python.org";>python.org</a> and start from there. A
basic Python installation should take 20-30 MB of disk space.</p>
</li>
@@ -560,6 +671,13 @@
have one, the Mixminion build process can download and compile one
for you.</li>
</ul>
+<p>To run Mixminion on Windows, you'll need:
+<ul>
+ <li>Windows 98 or later.</li>
+ <li>Optionally, Python 2.3. (If you don't have it, you can download
+ the standalone Mixminion distribution.)</li>
+ <li>Enough disk space.</li>
+</ul>
</div>
<h3>What do I need in order to run a Mixminion server?</h3>
@@ -569,8 +687,7 @@
client. Additionally, you'll need all of the following to run a
server:</p>
<ul>
- <li>A fixed IP address. (Dynamic IP support is scheduled for
- Mixminion 0.0.6.)</li>
+ <li>A DNS entry for your server, or a fixed IP address.</li>
<li>Enough disk space to hold logs and pending messages. 20-30 MB
should be enough for pending messages for now. If you're running
with verbose logs, you'll need about 2MB per day to hold them.
@@ -597,8 +714,8 @@
<div class="answer">
<p>There are instructions in each version of the release
notes. (That's the file entitled "README" in the Mixminion
- distribution.) Additionally, versions of Mixminion since 0.0.5
- include a manual page for client functionality.
+ distribution.) <!-- Additionally, versions of Mixminion since 0.0.5
+ include a manual page for client functionality. -->
</p>
</div>
@@ -613,8 +730,9 @@
<ul>
<li>Use Mixminion as an external program; invoke it as a separate
process, and parse the output.</li>
- <li>If you're writing in Python, invoke the functions in the module
- <tt>mixminion.ClientMain</tt> directly. (Be aware version 0.0.6,
+ <li>If you're writing in Python, invoke the functions in the module
+ <tt>mixminion.ClientMain</tt> directly. (Be aware that in some later
+ version,
these functions will change in order to more closely support the
proposed <a href="http://mixminion.net/api-spec.txt";>Client API</a>.)
</li>
@@ -651,14 +769,9 @@
written in C.)</p>
</div>
-<h3>When will Mixminion run on Windows?</h3>
+<h3>How much of the protocol is implemented?</h3>
<div class="answer">
-<p>When version 0.0.6 is released, it will have command-line support
- for Windows 98 and later. Some of the code is already written, but
- more testing and infrastructure are needed.</p>
-<p>Mixminion 0.0.5 already runs on Windows under Cygwin. If you're
- not a Unix person, you probably don't want to bother with
- Cygwin.</p>
+<p></p>
</div>
<h3>When will it have (insert feature here)?</h3>
@@ -679,6 +792,7 @@
<tr><td>From 0.0.2 to 0.0.3</td><td>~1.5 months</td></tr>
<tr><td>From 0.0.3 to 0.0.4</td><td>~3.75 months</td></tr>
<tr><td>From 0.0.4 to 0.0.5</td><td>~2.75 months</td></tr>
+<tr><td>From 0.0.5 to 0.0.6</td><td>~3 months</td></tr>
</table>
<p>Nick says that he's trying to shoot for a two month release cycle,
but this may be too ambitious.</p>
@@ -686,7 +800,7 @@
<h3>How do I report a bug in the code?</h3>
<div class="answer">
-<p>Preferably, go to the Mixminion bugzilla page at
+<p>Preferably, go to the Mixminion bugzilla page at
<a href="http://bugs.noreply.org";>bugs.noreply.org</a>.</p>
<p>If this isn't feasible, send email to the list at
mixminion-dev@freehaven.net, or to Nick Mathewson at
@@ -717,7 +831,7 @@
version 4.</p>
<p>Others have expressed interest in writing Type III client libraries
in C, but no announcements have been made and code has yet been
- publicly released.
+ publicly released.</p>
</div>
<h3>
@@ -746,6 +860,6 @@
editor will delete it and the writing will be just as it should
be. - Mark Twain.
-->
-
+
</body>
</html>