]> git.ipfire.org Git - thirdparty/tor.git/commitdiff
add puzzles-tls cite
authorRoger Dingledine <arma@torproject.org>
Mon, 3 Nov 2003 01:25:41 +0000 (01:25 +0000)
committerRoger Dingledine <arma@torproject.org>
Mon, 3 Nov 2003 01:25:41 +0000 (01:25 +0000)
svn:r722

doc/tor-design.bib
doc/tor-design.tex

index a018ca7dbd5e673dafa06677edbc0be4d2fb84d1..da8a0dfcb59a3207c48d52a310765b349f79db60 100644 (file)
    note =        {\url{http://www.abditum.com/mixmaster-spec.txt}},
 }
 
+@InProceedings{puzzles-tls,
+    author = "Drew Dean and Adam Stubblefield",
+    title = {{Using Client Puzzles to Protect TLS}},
+    booktitle = "Proceedings of the 10th USENIX Security Symposium",
+    year = {2001},
+    month = Aug,
+    publisher = {USENIX},
+}
+
+@InProceedings{breadpudding,
+  author =       {Markus Jakobsson and Ari Juels},
+  title =        {Proofs of Work and Bread Pudding Protocols},
+  booktitle =    {Proceedings of the IFIP TC6 and TC11 Joint Working
+                  Conference on Communications and Multimedia Security
+                  (CMS '99)},
+  year =         1999,
+  month =        {September},
+  publisher =    {Kluwer}
+}
+
 @Misc{hashcash,
    author =      {Adam Back},
    title =       {Hash cash},
index 7b3a4e8cbb1a9e33dfde22fe2c8b2014dc3ce433..6385657f427293c0f6452fedd4ed4a1daf001117 100644 (file)
@@ -913,7 +913,7 @@ see Section~\ref{sec:maintaining-anonymity} for more discussion.
 
 \Section{Other design decisions}
 
-\SubSection{Resource management and denial-of-service prevention}
+\SubSection{Resource management and denial-of-service}
 \label{subsec:dos}
 
 Providing Tor as a public service provides many opportunities for an
@@ -935,14 +935,14 @@ fake the start of a TLS handshake, forcing the OR to carry out its
 cost to the attacker.
 
 Several approaches exist to address these attacks. First, ORs may
-demand proof-of-computation tokens \cite{hashcash} before beginning new
+require clients to solve a puzzle \cite{puzzles-tls} while beginning new
 TLS handshakes or accepting \emph{create} cells.  So long as these
 tokens are easy to verify and computationally expensive to produce, this
-approach limits the DoS attack multiplier.  Additionally, ORs may limit
+approach limits the attack multiplier.  Additionally, ORs may limit
 the rate at which they accept create cells and TLS connections, so that
 the computational work of processing them does not drown out the (comparatively
 inexpensive) work of symmetric cryptography needed to keep cells
-flowing.  This rate limiting could, however, allows an attacker
+flowing.  This rate limiting could, however, allow an attacker
 to slow down other users when they build new circuits.
 
 % What about link-to-link rate limiting?