mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-12-06 19:41:15 +01:00
add puzzles-tls cite
svn:r722
This commit is contained in:
@@ -522,6 +522,26 @@
|
||||
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},
|
||||
|
||||
@@ -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?
|
||||
|
||||
Reference in New Issue
Block a user