[minion-cvs] Wrap paragraphs that don"t fit in an 80 col terminal

[nickm@seul.org (Nick Mathewson)]

Update of /home/minion/cvsroot/doc
In directory moria.seul.org:/tmp/cvs-serv4202

Modified Files:
	minion-design.tex 
Log Message:
Wrap paragraphs that don't fit in an 80 col terminal

Index: minion-design.tex
===================================================================
RCS file: /home/minion/cvsroot/doc/minion-design.tex,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -d -r1.12 -r1.13
--- minion-design.tex	2 May 2002 05:53:50 -0000	1.12
+++ minion-design.tex	2 May 2002 15:01:15 -0000	1.13
@@ -267,28 +267,30 @@
 
 \subsection{Link-level encryption and what it gets us}
 
-Unlike remailer types I and II that used SMTP as their underlying 
-transport mechanism, Mixminion clients and nodes communicate 
-using a forward secure encrypted channel based on TLS \cite{TLS}.
-TLS allows the establishment of an encrypted tunnel using ephemeral 
-Diffie-Hellman keys. In order to make sure that the receiving end is the 
-one intended by the creator of the anonymous message, the ephemeral key could be 
-signed by the receiving node. As soon as a session key has been established 
-the Diffie-Hellman keys are destroyed and messages start being sent through the
-tunnel. After each message a standard key update operation is performed to generate 
-a new key and the old key material is deleted. Key updates don't use any
-asymmetric encryption techniques, so they are quite fast.
+Unlike remailer types I and II that used SMTP as their underlying
+transport mechanism, Mixminion clients and nodes communicate using a
+forward secure encrypted channel based on TLS \cite{TLS}.  TLS allows
+the establishment of an encrypted tunnel using ephemeral
+Diffie-Hellman keys. In order to make sure that the receiving end is
+the one intended by the creator of the anonymous message, the
+ephemeral key could be signed by the receiving node. As soon as a
+session key has been established the Diffie-Hellman keys are destroyed
+and messages start being sent through the tunnel. After each message a
+standard key update operation is performed to generate a new key and
+the old key material is deleted. Key updates don't use any asymmetric
+encryption techniques, so they are quite fast.
 
-The above scheme offers forward secrecy in the sense that even the nodes 
-that exchange messages are not able to decrypt or even recognize 
-messages that might have been intercepted on the links. This makes it impossible 
-to comply with decryption notices that might be served in some jurisdiction.
-It also makes it necessary for an adversary to corrupt and control nodes in order
-to have enough information to trace back a forward anonymous communication by 
-requesting nodes to decrypt it. (Reply blocks can still be used for this purpose.)
-Even if an attacker manages to get hold of the session key at a particular point
-they would have to observe all subsequent traffic to be able to update their key
-appropriately. 
+The above scheme offers forward secrecy in the sense that even the
+nodes that exchange messages are not able to decrypt or even recognize
+messages that might have been intercepted on the links. This makes it
+impossible to comply with decryption notices that might be served in
+some jurisdiction.  It also makes it necessary for an adversary to
+corrupt and control nodes in order to have enough information to trace
+back a forward anonymous communication by requesting nodes to decrypt
+it. (Reply blocks can still be used for this purpose.)  Even if an
+attacker manages to get hold of the session key at a particular point
+they would have to observe all subsequent traffic to be able to update
+their key appropriately.
 
 The forward secure encrypted channel offers only limited protection
 against traffic analysis. Encrypted links between honest nodes prevent