aboutsummaryrefslogtreecommitdiff
path: root/spec/dos-spec
diff options
context:
space:
mode:
authorMicah Elizabeth Scott <beth@torproject.org>2023-11-09 14:00:01 -0800
committerMicah Elizabeth Scott <beth@torproject.org>2023-11-09 14:16:27 -0800
commit1d7274bdcc7d46b0aec43ed44d99d2d7362593e5 (patch)
tree164f87aaec0d7c2e6f8437cda953600376aedc00 /spec/dos-spec
parentd3987e6889a51beef81bc7f4735c3749cd9fc78b (diff)
downloadtorspec-1d7274bdcc7d46b0aec43ed44d99d2d7362593e5.tar.gz
torspec-1d7274bdcc7d46b0aec43ed44d99d2d7362593e5.zip
Another editing pass for hspow-spec and friends
This mostly updates formatting and links. I added a little bit of new context, primarily a disclaimer and updated benchmark info for analysis-discussion.md
Diffstat (limited to 'spec/dos-spec')
-rw-r--r--spec/dos-spec/overview.md6
1 files changed, 3 insertions, 3 deletions
diff --git a/spec/dos-spec/overview.md b/spec/dos-spec/overview.md
index e159014..0ea0994 100644
--- a/spec/dos-spec/overview.md
+++ b/spec/dos-spec/overview.md
@@ -7,7 +7,7 @@ These mitigations are expected to improve network availability, but DoS mitigati
The attack and defense environment changes over time.
Expect that this document is an attempt to describe the current state of things, but that it may not be complete.
-The defenses here are organized by the type of resource under contention. These can be physical resources (Memory, CPU, Bandwidth) or protocol resources (Connections, Circuits, Introductions).
+The defenses here are organized by the type of resource under contention. These can be physical resources ([Memory](#memory), [CPU](#cpu), [Bandwidth](#bandwidth)) or protocol resources ([Channels](#channels), [Circuits](#circuits), [Introductions](#hs-intro)).
In practice there are always overlaps between these resource types.
Connecting to an onion service, for example, puts some strain on every resource type here.
@@ -73,6 +73,6 @@ Based on the queue behavior, servers will continuously provide an updated effort
Queue backlogs cause the effort to rise, and an idle server will cause the effort to decay.
If the queue is never overfull the effort decays to zero, asking clients not to include a proof-of-work solution at all.
-We may support multiple cryptographic algorithms for this puzzle in the future, but currently we support one type. It's called `v1` in our protocol, and it's based on the Equi-X algorithm developed for this purpose. See the document on [`Proof of Work for onion service introduction`](../hspow-spec/index.md).
+We may support multiple cryptographic algorithms for this puzzle in the future, but currently we support one type. It's called `v1` in our protocol, and it's based on the Equi-X algorithm developed for this purpose. See the document on [Proof of Work for onion service introduction](../hspow-spec/index.md).
-This defense is configured by an operator using the `HiddenServicePoW` configuration options. Additionally, it requires both the client and the onion service to be compiled with the `pow` module (`--enable-gpl` mode) available. Current versions of the Tor Browser do include `pow` support.
+This defense is configured by an operator using the `HiddenServicePoW` configuration options. Additionally, it requires both the client and the onion service to be compiled with the `pow` module (and `--enable-gpl` mode) available. Despite this non-default build setting, proof of work *is* available through common packagers like the Tor Browser and Debian.