diff options
Diffstat (limited to 'spec/rend-spec-v3/protocol-overview.md')
| -rw-r--r-- | spec/rend-spec-v3/protocol-overview.md | 18 |
1 files changed, 9 insertions, 9 deletions
diff --git a/spec/rend-spec-v3/protocol-overview.md b/spec/rend-spec-v3/protocol-overview.md index 173240e..afc2dd1 100644 --- a/spec/rend-spec-v3/protocol-overview.md +++ b/spec/rend-spec-v3/protocol-overview.md @@ -8,7 +8,7 @@ fully below, when we specify the protocol in more detail. <a id="rend-spec-v3.txt-1.1"></a> -## View from 10,000 feet +## View from 10,000 feet {#10000-feet} A hidden service host prepares to offer a hidden service by choosing several Tor nodes to serve as its introduction points. It builds @@ -47,7 +47,7 @@ communicate data on those streams, and so forth. <a id="rend-spec-v3.txt-1.2"></a> -## In more detail: naming hidden services \[NAMING\] +## In more detail: naming hidden services {#NAMING} A hidden service's name is its long term master identity key. This is encoded as a hostname by encoding the entire key in Base 32, including a @@ -73,7 +73,7 @@ their length. An older name might look like: <a id="rend-spec-v3.txt-1.3"></a> -## In more detail: Access control \[IMD:AC\] +## In more detail: Access control {#IMD:AC} Access control for a hidden service is imposed at multiple points through the process above. Furthermore, there is also the option to impose @@ -108,7 +108,7 @@ require the client to prove knowledge of a pre-shared private key. <a id="rend-spec-v3.txt-1.4"></a> -## In more detail: Distributing hidden service descriptors. \[IMD:DIST\] +## In more detail: Distributing hidden service descriptors. {#IMD:DIST} Periodically, hidden service descriptors become stored at different locations to prevent a single directory or small set of directories @@ -153,7 +153,7 @@ until the new keys come online. <a id="rend-spec-v3.txt-1.5"></a> -## In more detail: Scaling to multiple hosts +## In more detail: Scaling to multiple hosts {#imd-scaling} This design is compatible with our current approaches for scaling hidden services. Specifically, hidden service operators can use onionbalance to @@ -175,7 +175,7 @@ introduction points. <a id="rend-spec-v3.txt-1.7"></a> -## In more detail: Keeping crypto keys offline +## In more detail: Keeping crypto keys offline {#imd-offline-keys} In this design, a hidden service's secret identity key may be stored offline. It's used only to generate blinded signing keys, @@ -202,7 +202,7 @@ implemented as of 0.3.2.1-alpha.) <a id="rend-spec-v3.txt-1.8"></a> -## In more detail: Encryption Keys And Replay Resistance +## In more detail: Encryption Keys And Replay Resistance {#imd-encryption-keys} To avoid replays of an introduction request by an introduction point, a hidden service host must never accept the same request @@ -213,7 +213,7 @@ discussion.) <a id="rend-spec-v3.txt-1.9"></a> -## In more detail: A menagerie of keys +## In more detail: A menagerie of keys {#imd-key-menagerie} \[In the text below, an "encryption keypair" is roughly "a keypair you can do Diffie-Hellman with" and a "signing keypair" is roughly "a @@ -292,7 +292,7 @@ Public/private keypairs defined in this document: <a id="rend-spec-v3.txt-1.9.1"></a> -### In even more detail: Client authorization keys \[CLIENT-AUTH\] +### In even more detail: Client authorization keys {#CLIENT-AUTH} When client authorization is enabled, each authorized client of a hidden service has two more asymmetric keypairs which are shared with the hidden |