[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/main] prop331: Fix typos
commit 42d62072d27e0415274c9987e1291001ff601e7f
Author: Georg Koppen <gk@xxxxxxxxxxxxxx>
Date: Sun Jun 13 10:15:04 2021 +0000
prop331: Fix typos
---
proposals/331-res-tokens-for-anti-dos.md | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/proposals/331-res-tokens-for-anti-dos.md b/proposals/331-res-tokens-for-anti-dos.md
index 23e2aa9..a7293e8 100644
--- a/proposals/331-res-tokens-for-anti-dos.md
+++ b/proposals/331-res-tokens-for-anti-dos.md
@@ -40,12 +40,12 @@ Status: Draft
- Tor proposal #327 increases the attacker's computational requirements (not implemented yet).
While the above proposals in tandem should provide reasonable protection
- against many DoS attackers, they fundamentally work by reducing the assymetry
+ against many DoS attackers, they fundamentally work by reducing the asymmetry
between the onion service and the attacker. This won't work if the attacker
- is extremely powerful because the assymetry is already huge and cutting it
+ is extremely powerful because the asymmetry is already huge and cutting it
down does not help.
- we believe that a proposal based on cryptographic guarantees -- like Res
+ We believe that a proposal based on cryptographic guarantees -- like Res
tokens -- can offer protection against even extremely strong attackers.
# 2. Overview
@@ -71,7 +71,7 @@ Status: Draft
# 3. Design [TOKEN_DESIGN]
- In this section we will go over the high-level design of the system, and on
+ In this section we will go over the high-level design of the system, and in
the next section we will delve into the lower-level details of the protocol.
## 3.1. Anonymous credentials
@@ -261,7 +261,7 @@ Status: Draft
[At most once]
token-type: Is the type of token supported ("res" for this proposal)
- issuer: A comma separated list of issuers which are supported by this onion service
+ issuer-list: A comma separated list of issuers which are supported by this onion service
## 4.3. Token issuance
@@ -381,7 +381,7 @@ Status: Draft
XXX maybe with a bit of tweaking we can even use a 1536-bit RSA signature here...
-### 4.4.2. Onion service verifies token [RES_VERIFY]
+### 4.4.2. Onion service verifies token [RES_VERIFY]
Upon receiving an INTRODUCE1 cell with the above extension the service
verifies the token. It does so as follows:
@@ -389,8 +389,8 @@ Status: Draft
1) The service checks its double spend protection cache for an element that
matches DEST_DIGEST. If one is found, verification fails.
2) The service checks: DEST_DIGEST == FDH_N(service_pubkey || SALT), where
- 'service_pubkey' is its own long-term identity pubkey.
- 3) The service finds the corresponding issuer pubkey 'e' based on ISSUER_KEY
+ 'service_pubkey' is its own long-term public identity key.
+ 3) The service finds the corresponding issuer public key 'e' based on ISSUER_KEY
from the consensus or its configuration file
4) The service checks: TOKEN ^ e == DEST_DIGEST
@@ -399,7 +399,7 @@ Status: Draft
double spend protection cache by maintaining a sorted array of truncated
DEST_DIGEST elements.
- If any of the above steps fail, the verification process aborts and the
+ If any of the above steps fails, the verification process aborts and the
introduction request gets discarded.
If all the above verification steps have been completed successfully, the
@@ -514,7 +514,7 @@ Status: Draft
however we didn't expand on those use cases to keep the proposal short. In
the future, we might want to split this document into two proposals: one
proposal that specifies the token scheme, and another that specifies how to
- use it in the context of onion servicves, so that we can then write more
+ use it in the context of onion services, so that we can then write more
proposals that use the token scheme as a primitive.
An extremely relevant use case would be to use Res tokens as a way to protect
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits