From 7b1c44fb6a7cd1d5b78e6f6638d5c5d2c9652b19 Mon Sep 17 00:00:00 2001 From: Silvio Rhatto Date: Wed, 19 Jul 2023 17:51:19 -0300 Subject: Prop 327: fix minor typos --- proposals/327-pow-over-intro.txt | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/proposals/327-pow-over-intro.txt b/proposals/327-pow-over-intro.txt index 6ce610e..3765b8b 100644 --- a/proposals/327-pow-over-intro.txt +++ b/proposals/327-pow-over-intro.txt @@ -40,7 +40,7 @@ Status: Draft This proposal is written to thwart specific attackers. A simple PoW proposal cannot defend against all and every DoS attack on the Internet, but there are - adverary models we can defend against. + adversary models we can defend against. Let's start with some adversary profiles: @@ -48,21 +48,21 @@ Status: Draft The script-kiddie has a single computer and pushes it to its limits. Perhaps it also has a VPS and a pwned server. We are talking about - an attacker with total access to 10 Ghz of CPU and 10 GBs of RAM. We + an attacker with total access to 10 GHz of CPU and 10 GB of RAM. We consider the total cost for this attacker to be zero $. "The small botnet" The small botnet is a bunch of computers lined up to do an introduction flooding attack. Assuming 500 medium-range computers, we are talking about - an attacker with total access to 10 Thz of CPU and 10 TB of RAM. We + an attacker with total access to 10 THz of CPU and 10 TB of RAM. We consider the upfront cost for this attacker to be about $400. "The large botnet" The large botnet is a serious operation with many thousands of computers organized to do this attack. Assuming 100k medium-range computers, we are - talking about an attacker with total access to 200 Thz of CPU and 200 TB of + talking about an attacker with total access to 200 THz of CPU and 200 TB of RAM. The upfront cost for this attacker is about $36k. We hope that this proposal can help us defend against the script-kiddie @@ -78,7 +78,7 @@ Status: Draft This is a standard laptop/desktop user who is trying to browse the web. They don't know how these defences work and they don't care to configure or tweak them. If the site doesn't load, they are gonna close - their browser and be sad at Tor. They run a 2Ghz computer with 4GB of RAM. + their browser and be sad at Tor. They run a 2GHz computer with 4GB of RAM. "The motivated user" @@ -156,9 +156,9 @@ Status: Draft 2.2.1. Algorithm overview For our proof-of-work function we will use the Equi-X scheme by tevador - [REF_EQUIX]. Equi-X is an assymetric PoW function based on Equihash<60,3>, + [REF_EQUIX]. Equi-X is an asymmetric PoW function based on Equihash<60,3>, using HashX as the underlying layer. It features lightning fast verification - speed, and also aims to minimize the assymetry between CPU and GPU. + speed, and also aims to minimize the asymmetry between CPU and GPU. Furthermore, it's designed for this particular use-case and hence cryptocurrency miners are not incentivized to make optimized ASICs for it. @@ -178,7 +178,7 @@ Status: Draft 4) The PoW protocol itself builds on this Equi-X function with a particular construction of the challenge input and particular constraints on the allowed blake2b hash of the solution. This layer provides a linearly - adjustible effort that we can verify. + adjustable effort that we can verify. 5) Above the level of individual PoW handshakes, the client and service form a closed-loop system that adjusts the effort of future handshakes. @@ -302,7 +302,7 @@ Status: Draft that will cause unacceptably long PoW computation. The client uses a "personalization string" P equal to the following - nul-terminated ascii string: "Tor hs intro v1\0". + nul-terminated ASCII string: "Tor hs intro v1\0". The client looks up `ID`, the current 32-byte blinded public ID (KP_hs_blind_id) for the onion service. @@ -682,7 +682,7 @@ Status: Draft 5.1.4. Gaming the effort estimation logic [ATTACK_EFFORT] Another way to beat this system is for the attacker to game the effort - estimation logic (see [EFFORT_ESTIMATION]). Essentialy, there are two attacks + estimation logic (see [EFFORT_ESTIMATION]). Essentially, there are two attacks that we are trying to avoid: - Attacker sets descriptor suggested-effort to a very high value effectively @@ -734,7 +734,7 @@ Status: Draft Verifying a PoW token is the first thing that a service does when it receives an INTRODUCE2 cell and it's detailed in section [POW_VERIFY]. This verification happens during the "top half" part of the process. Every - milisecond spent verifying PoW adds overhead to the already existing "top + millisecond spent verifying PoW adds overhead to the already existing "top half" part of handling an introduction cell. Hence we should be careful to add minimal overhead here so that we don't enable attacks like [ATTACK_TOP_HALF]. @@ -796,7 +796,7 @@ Status: Draft The difficulty setting of our PoW basically dictates how difficult it should be to get a success in our PoW system. An attacker who can get many successes - per second can pull a successfull [ATTACK_BOTTOM_HALF] attack against our + per second can pull a successful [ATTACK_BOTTOM_HALF] attack against our system. In classic PoW systems, "success" is defined as getting a hash output below @@ -936,7 +936,7 @@ Status: Draft This proposal suffers from various UX issues because there is no end-to-end mechanism for an onion service to inform the client about its introduction request. If we had end-to-end introduction ACKs many of the problems from - [CLIENT_BEHAVIOR] would be aleviated. The problem here is that end-to-end + [CLIENT_BEHAVIOR] would be alleviated. The problem here is that end-to-end ACKs require modifications on the introduction point code and a network update which is a lengthy process. @@ -949,7 +949,7 @@ Status: Draft 7.2.2. Future designs [FUTURE_DESIGNS] This is just the beginning in DoS defences for Tor and there are various - futured designs and schemes that we can investigate. Here is a brief summary + future designs and schemes that we can investigate. Here is a brief summary of these: "More advanced PoW schemes" -- We could use more advanced memory-hard PoW @@ -1176,7 +1176,7 @@ A.4.1 Tor measurements [TOR_MEASUREMENTS] There is an average of 2.42 INTRODUCE2 cells per mainloop event and so we divide that by the full mainloop event mean time to get the time for one - cell. From that we substract the "bottom half" mean time to get how much + cell. From that we subtract the "bottom half" mean time to get how much the "top half" takes: => 13.43 / (7931 / 3279) = 5.55 -- cgit v1.2.3-54-g00ecf