This is an automated email from the git hooks/post-receive script.
nickm pushed a change to branch main in repository torspec.
from 103c772 Merge branch 'tor-gitlab/mr/102' new da8eced Rename three keys. new d44927c Name and clarify a few more objects. new c51fa4c Remove K_desc_enc. new 2e8606c Fix name of KP_hs_blind_id new 0b1289f Remove mention of "password" auth in rend-spec. new b7aeade Grammar fix new 5c6b282 Call the key in desc-auth-ephemeral-key, KP_hs_desc_ephem new 7b3d7a4 Use proper names for KP_hsc_desc_enc new e4596ec Merge branch 'hs-desc-ephem' into 'main' new 431f615 Fix terminology for handshake type new 3951336 Put HTYPE (the name for this thing) in the title for the table new 46356d2 Merge branch 'hs-htype' into 'main' new 71d7e71 Rename hs_index and hsdir_index to hs_{service,relay}_index new 4234d93 Merge remote-tracking branches 'tor-gitlab/mr/114' and 'tor-gitlab/mr/115'
The 14 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference.
Summary of changes: rend-spec-v3.txt | 93 +++++++++++++++++++++++++++++--------------------------- tor-spec.txt | 4 +-- 2 files changed, 51 insertions(+), 46 deletions(-)
This is an automated email from the git hooks/post-receive script.
nickm pushed a commit to branch main in repository torspec.
commit 5c6b282e57f866a1341eb705cb21507fcbfcc543 Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Mon Feb 6 12:25:55 2023 +0000
Call the key in desc-auth-ephemeral-key, KP_hs_desc_ephem
Proposed by @nickm in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/999/diffs#50f97...
(I think the spec is not 100% clear that hs_y and hs_Y are *this* key, rather than some other possible ephemeral keypair the HS might have, so please would the reviewer check that this is actually true.) --- rend-spec-v3.txt | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index a8ac264..afc2a46 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -1208,7 +1208,7 @@ Table of contents:
If client authorization is disabled, the value here should be "x25519".
- "desc-auth-ephemeral-key" SP key NL + "desc-auth-ephemeral-key" SP KP_hs_desc_ephem NL
[Exactly once]
@@ -1239,13 +1239,11 @@ Table of contents:
client_x = private x25519 key of authorized client client_X = public x25519 key of authorized client - hs_y = private key of ephemeral x25519 keypair of hidden service - hs_Y = public key of ephemeral x25519 keypair of hidden service descriptor_cookie = descriptor cookie used to encrypt the descriptor
And here is what the hidden service computes:
- SECRET_SEED = x25519(hs_y, client_X) + SECRET_SEED = x25519(KS_hs_desc_ephem, client_X) KEYS = KDF(N_hs_subcred | SECRET_SEED, 40) CLIENT-ID = fist 8 bytes of KEYS COOKIE-KEY = last 32 bytes of KEYS
This is an automated email from the git hooks/post-receive script.
nickm pushed a commit to branch main in repository torspec.
commit 7b3d7a40a0ac8f59b9f6d79205dfc53de4168f0c Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Mon Feb 6 12:51:41 2023 +0000
Use proper names for KP_hsc_desc_enc --- rend-spec-v3.txt | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index afc2a46..805e0d9 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -1231,19 +1231,17 @@ Table of contents:
When client authorization is enabled, each "auth-client" line contains the descriptor cookie encrypted to each individual client. We assume that - each authorized client possesses a pre-shared x25519 keypair which is - used to decrypt the descriptor cookie. + each authorized client possesses a pre-shared x25519 keypair + KS/KP_hsc_desc_enc which is used to decrypt the descriptor cookie.
We now describe the descriptor cookie encryption scheme. Here are the relevant keys:
- client_x = private x25519 key of authorized client - client_X = public x25519 key of authorized client descriptor_cookie = descriptor cookie used to encrypt the descriptor
And here is what the hidden service computes:
- SECRET_SEED = x25519(KS_hs_desc_ephem, client_X) + SECRET_SEED = x25519(KS_hs_desc_ephem, KP_hsc_desc_enc) KEYS = KDF(N_hs_subcred | SECRET_SEED, 40) CLIENT-ID = fist 8 bytes of KEYS COOKIE-KEY = last 32 bytes of KEYS
This is an automated email from the git hooks/post-receive script.
nickm pushed a commit to branch main in repository torspec.
commit 431f6152cf24f337a737d0c215137e25f29436d9 Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Mon Feb 6 14:51:45 2023 +0000
Fix terminology for handshake type
The phrase "format number" is not defined anywhere. I think it means an HTYPE value. --- rend-spec-v3.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index a8ac264..12c1c43 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -1348,10 +1348,10 @@ Table of contents:
[Exactly once]
- A space-separated list of integers denoting CREATE2 cell format numbers - that the server recognizes. Must include at least ntor as described in - tor-spec.txt. See tor-spec section 5.1 for a list of recognized - handshake types. + A space-separated list of integers denoting CREATE2 cell HTYPEs + (handshake types) that the server recognizes. Must include at least + ntor as described in tor-spec.txt. See tor-spec section 5.1 for a list + of recognized handshake types.
"intro-auth-required" SP types NL
This is an automated email from the git hooks/post-receive script.
nickm pushed a commit to branch main in repository torspec.
commit 39513369c7bc3c29a8514b2048ad08f42376b034 Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Mon Feb 6 14:52:47 2023 +0000
Put HTYPE (the name for this thing) in the title for the table --- tor-spec.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tor-spec.txt b/tor-spec.txt index e522135..9aa4cc4 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -1022,7 +1022,7 @@ see tor-design.pdf. HLEN (Server Handshake Data Len) [2 bytes] HDATA (Server Handshake Data) [HLEN bytes]
- Recognized handshake types are: + Recognized HTYPEs (handshake types) are:
0x0000 TAP -- the original Tor handshake; see 5.1.3 0x0001 reserved
This is an automated email from the git hooks/post-receive script.
nickm pushed a commit to branch main in repository torspec.
commit e4596ecced32a08c0d9437722fe6354092e405ec Merge: 103c772 7b3d7a4 Author: Nick Mathewson nickm@torproject.org AuthorDate: Mon Feb 6 21:00:24 2023 +0000
Merge branch 'hs-desc-ephem' into 'main'
Call the key in desc-auth-ephemeral-key, KP_hs_desc_ephem
See merge request tpo/core/torspec!111
rend-spec-v3.txt | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-)
This is an automated email from the git hooks/post-receive script.
nickm pushed a commit to branch main in repository torspec.
commit 46356d252f16e20b3d7e6db24a51076bc90b8855 Merge: e4596ec 3951336 Author: Nick Mathewson nickm@torproject.org AuthorDate: Mon Feb 6 21:01:00 2023 +0000
Merge branch 'hs-htype' into 'main'
Fix terminology for handshake type
See merge request tpo/core/torspec!112
rend-spec-v3.txt | 8 ++++---- tor-spec.txt | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-)
This is an automated email from the git hooks/post-receive script.
nickm pushed a commit to branch main in repository torspec.
commit da8ecedde5c62d2d48930d8ec09708cd123b2258 Author: Nick Mathewson nickm@torproject.org AuthorDate: Tue Feb 7 14:51:08 2023 -0500
Rename three keys.
These names are slightly shorter and a bit more descriptive IMO, and now (when they are still fresh) is the best time to rename these keys.
`hs_intro_tid` becomes `hs_ipt_sid`: It is a _session identifier_ key used with an _introduction point_. Using `ipt` here emphasizes that it is not part of the introduction _handshake_.
`hs_intro_ntor` becomes `hss_ntor`. The extra "s" means it is owned by the service. Renaming "intro" here removes the implication that it is held by or used by the introduction point.
`onion_ntor` becomes `ntor`: There is no such thing as an ntor key that is not an onion key. --- rend-spec-v3.txt | 14 +++++++------- tor-spec.txt | 2 +- 2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index a8ac264..76d02cf 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -611,14 +611,14 @@ Table of contents: can get their introduction requests sent to the right service. No keypair is ever used with more than one introduction point. (previously called a "service key" in rend-spec.txt) - KP_hs_intro_tid, KS_hs_intro_tid + KP_hs_ipt_sid, KS_hs_ipt_sid ("hidden service introduction point temporary id").
Introduction point encryption key -- A short-term encryption keypair used when establishing connections via an introduction point. Plays a role analogous to Tor nodes' onion keys. A fresh keypair is made for each introduction point. - KP_hs_intro_ntor, KS_hs_intro_ntor. + KP_hss_ntor, KS_hss_ntor.
Symmetric keys defined in this document:
@@ -629,7 +629,7 @@ Table of contents:
Public/private keypairs defined elsewhere:
- Onion key -- Short-term encryption keypair (KS_onion_ntor, KP_onion_ntor). + Onion key -- Short-term encryption keypair (KS_ntor, KP_ntor).
(Node) identity key (KP_relayid).
@@ -1419,7 +1419,7 @@ Table of contents:
The certificate is a proposal 220 certificate wrapped in "-----BEGIN ED25519 CERT-----". It contains the introduction - point authentication key (`KP_hs_intro_tid`), signed by + point authentication key (`KP_hs_ipt_sid`), signed by the descriptor signing key (`KP_hs_desc_sign`). The certificate type must be [09], and the signing key extension is mandatory. @@ -1438,7 +1438,7 @@ Table of contents: [Exactly once per introduction point]
The key is a base64 encoded curve25519 public key used to encrypt - the introduction request to service. (`KP_hs_intro_ntor`) + the introduction request to service. (`KP_hss_ntor`)
"enc-key" SP KeyType SP key.. NL
@@ -1458,7 +1458,7 @@ Table of contents: For "ntor" keys, certificate is a proposal 220 certificate wrapped in "-----BEGIN ED25519 CERT-----" armor. The subject key is the the ed25519 equivalent of a curve25519 public - encryption key (`KP_hs_intro_ntor`), with the ed25519 key + encryption key (`KP_hss_ntor`), with the ed25519 key derived using the process in proposal 228 appendix A. The signing key is the descriptor signing key (`KP_hs_desc_sign`). The certificate type must be [0B], and the signing-key @@ -1468,7 +1468,7 @@ Table of contents: constructed the other way around. However, for compatibility with C tor, implementations need to construct it this way. It serves even less point than "auth-key", however, since the - encryption key `KP_hs_intro_ntor` is already available from + encryption key `KP_hss_ntor` is already available from the `enc-key` entry.
"legacy-key" NL key NL diff --git a/tor-spec.txt b/tor-spec.txt index e522135..b94add7 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -252,7 +252,7 @@ see tor-design.pdf. longer advertised. Because of this, relays MUST retain old keys for a while after they're rotated. (See "onion key lifetime parameters" in dir-spec.txt.) - KP_onion_ntor, KS_onion_ntor. + KP_ntor, KS_ntor.
These are Ed25519 keys:
This is an automated email from the git hooks/post-receive script.
nickm pushed a commit to branch main in repository torspec.
commit d44927c39e16bca7c95f60fee1a2ff33f0e39500 Author: Nick Mathewson nickm@torproject.org AuthorDate: Tue Feb 7 15:07:57 2023 -0500
Name and clarify a few more objects. --- rend-spec-v3.txt | 52 +++++++++++++++++++++++++++++++++++----------------- 1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 76d02cf..c9928e5 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -603,8 +603,8 @@ Table of contents: KP_hs_desc_sign, KS_hs_desc_sign.
Introduction point authentication key -- A short-term signing - keypair used to identify a hidden service to a given - introduction point. A fresh keypair is made for each + keypair used to identify a hidden service's session at a given + introduction point. The service makes a fresh keypair is made for each introduction point; these are used to sign the request that a hidden service host makes when establishing an introduction point, so that clients who know the public component of this key @@ -612,14 +612,20 @@ Table of contents: service. No keypair is ever used with more than one introduction point. (previously called a "service key" in rend-spec.txt) KP_hs_ipt_sid, KS_hs_ipt_sid - ("hidden service introduction point temporary id"). + ("hidden service introduction point session id").
Introduction point encryption key -- A short-term encryption keypair used when establishing connections via an introduction - point. Plays a role analogous to Tor nodes' onion keys. A fresh - keypair is made for each introduction point. + point. Plays a role analogous to Tor nodes' onion keys. The service + makes a fresh keypair is made for each introduction point. KP_hss_ntor, KS_hss_ntor.
+ Ephemeral descriptor encryption key -- A short-lived encryption + keypair made by the service, and used to encrypt the inner layer + of hidden service descriptors when client authentication is in + use. + KP_hss_desc_enc, KS_hss_desc_enc + Symmetric keys defined in this document:
Descriptor encryption keys -- A symmetric encryption key used to @@ -627,6 +633,12 @@ Table of contents: current period and the hidden service credential. K_desc_enc.
+ Nonces defined in this document: + + N_hs_desc_enc -- a nonce used to derive keys to decrypt the inner + encryption layer of hidden service descriptors. This is + sometimes also called a "descriptor cookie". + Public/private keypairs defined elsewhere:
Onion key -- Short-term encryption keypair (KS_ntor, KP_ntor). @@ -651,7 +663,8 @@ Table of contents: Specifically, each authorized client possesses:
- An x25519 keypair used to compute decryption keys that allow the client to - decrypt the hidden service descriptor. See [HS-DESC-ENC]. + decrypt the hidden service descriptor. See [HS-DESC-ENC]. This is + the client's counterpart to KP_hss_desc_enc. KP_hsc_desc_enc, KS_hsd_desc_enc.
- An ed25519 keypair which allows the client to compute signatures which @@ -1187,10 +1200,11 @@ Table of contents: "encrypted" field.
If client auth is enabled, the hidden service generates a fresh - descriptor_cookie key (32 random bytes) and encrypts it using each - authorized client's identity x25519 key. Authorized clients can use the - descriptor cookie to decrypt the second layer of encryption. Our encryption - scheme requires the hidden service to also generate an ephemeral x25519 + descriptor_cookie key (`N_hs_desc_enc`, 32 random bytes) and encrypts + it using each authorized client's identity x25519 key. Authorized + clients can use the descriptor cookie (`N_hs_desc_enc`) to decrypt + the second (inner) layer of encryption. Our encryption scheme + requires the hidden service to also generate an ephemeral x25519 keypair for each new descriptor.
If client auth is disabled, fake data is placed in each of the fields below @@ -1212,9 +1226,9 @@ Table of contents:
[Exactly once]
- This field contains an ephemeral x25519 public key generated by the - hidden service and encoded in base64. The key is used by the encryption - scheme below. + This field contains `KP_hss_desc_enc`, an ephemeral x25519 public + key generated by the hidden service and encoded in base64. The key + is used by the encryption scheme below.
If client authorization is disabled, the value here should be a fresh x25519 pubkey that will remain unused. @@ -1229,18 +1243,22 @@ Table of contents: data of the right size (that's 8 bytes for 'client-id', 16 bytes for 'iv' and 16 bytes for 'encrypted-cookie' all encoded with base64).
- When client authorization is enabled, each "auth-client" line contains - the descriptor cookie encrypted to each individual client. We assume that - each authorized client possesses a pre-shared x25519 keypair which is - used to decrypt the descriptor cookie. + When client authorization is enabled, each "auth-client" line + contains the descriptor cookie `N_hs_desc_enc` encrypted to each + individual client. We assume that each authorized client possesses + a pre-shared x25519 keypair (`KP_hsc_desc_enc`) which is used to + decrypt the descriptor cookie.
We now describe the descriptor cookie encryption scheme. Here are the relevant keys:
+ # KS/KP_hsc_desc_enc client_x = private x25519 key of authorized client client_X = public x25519 key of authorized client + # KS/KP_hss_desc_enc hs_y = private key of ephemeral x25519 keypair of hidden service hs_Y = public key of ephemeral x25519 keypair of hidden service + # N_hs_desc_enc descriptor_cookie = descriptor cookie used to encrypt the descriptor
And here is what the hidden service computes:
This is an automated email from the git hooks/post-receive script.
nickm pushed a commit to branch main in repository torspec.
commit c51fa4c53e1dcf441383cb4826f22fa63d26e812 Author: Nick Mathewson nickm@torproject.org AuthorDate: Tue Feb 7 15:08:27 2023 -0500
Remove K_desc_enc.
It has no independent existence outside of the encryption algorithm of 2.5.3. --- rend-spec-v3.txt | 7 ------- 1 file changed, 7 deletions(-)
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index c9928e5..e5c4cf1 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -626,13 +626,6 @@ Table of contents: use. KP_hss_desc_enc, KS_hss_desc_enc
- Symmetric keys defined in this document: - - Descriptor encryption keys -- A symmetric encryption key used to - encrypt the body of hidden service descriptors. Derived from the - current period and the hidden service credential. - K_desc_enc. - Nonces defined in this document:
N_hs_desc_enc -- a nonce used to derive keys to decrypt the inner
This is an automated email from the git hooks/post-receive script.
nickm pushed a commit to branch main in repository torspec.
commit 2e8606c1bb91b0d61bcbd098add9d5d1baeabc02 Author: Nick Mathewson nickm@torproject.org AuthorDate: Tue Feb 7 15:10:15 2023 -0500
Fix name of KP_hs_blind_id
By our current logic, it needs to have `hs` in it. --- rend-spec-v3.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index e5c4cf1..40d51bf 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -592,7 +592,7 @@ Table of contents: the public blinded identity key for a service. This key is used as an index in the DHT-like structure of the directory system (see [SUBCRED]). - KP_blind_id, KS_blind_id. + KP_hs_blind_id, KS_hs_blind_id.
Descriptor signing key -- A key used to sign hidden service descriptors. This is signed by blinded signing keys. Unlike
This is an automated email from the git hooks/post-receive script.
nickm pushed a commit to branch main in repository torspec.
commit 0b1289fd26271eff0eb77aed263d7fe010f7e436 Author: Nick Mathewson nickm@torproject.org AuthorDate: Tue Feb 7 15:10:54 2023 -0500
Remove mention of "password" auth in rend-spec.
It was never implemented, is not specified, and neither dgoulet nor I can quite remember how it was supposed to work. --- rend-spec-v3.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 40d51bf..9700dfb 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -1371,7 +1371,7 @@ Table of contents: A space-separated list of introduction-layer authentication types; see section [INTRO-AUTH] for more info. A client that does not support at least one of these authentication types will not be able to contact the - host. Recognized types are: 'password' and 'ed25519'. + host. Recognized types are: 'ed25519'.
"single-onion-service"
This is an automated email from the git hooks/post-receive script.
nickm pushed a commit to branch main in repository torspec.
commit 71d7e7184dc11e599afb881c7e15674532338512 Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Wed Feb 8 14:49:30 2023 +0000
Rename hs_index and hsdir_index to hs_{service,relay}_index
These new names are the ones used in arti's hsdir_ring.rs and make a lot more sense than calling one of them the "directory" index and the other just the "index".
In C Tor these are calculated by functions called hs_build_hs_index hs_build_hsdir_index
That might be a reason *not* to accept this change. Or it might be a reason to change the C Tor code.
If we don't change the names in the spec the Arti function names should change. --- rend-spec-v3.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 51267ec..672248e 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -811,7 +811,7 @@ Table of contents: derived, the uploading or downloading party calculates:
for replicanum in 1...hsdir_n_replicas: - hs_index(replicanum) = H("store-at-idx" | + hs_service_index(replicanum) = H("store-at-idx" | blinded_public_key | INT_8(replicanum) | INT_8(period_length) | @@ -825,7 +825,7 @@ Table of contents: Then, for each node listed in the current consensus with the HSDir flag, we compute a directory index for that node as:
- hsdir_index(node) = H("node-idx" | node_identity | + hs_relay_index(node) = H("node-idx" | node_identity | shared_random_value | INT_8(period_num) | INT_8(period_length) ) @@ -836,7 +836,7 @@ Table of contents:
Finally, for replicanum in 1...hsdir_n_replicas, the hidden service host uploads descriptors to the first hsdir_spread_store nodes whose - indices immediately follow hs_index(replicanum). If any of those + indices immediately follow hs_service_index(replicanum). If any of those nodes have already been selected for a lower-numbered replica of the service, any nodes already chosen are disregarded (i.e. skipped over) when choosing a replica's hsdir_spread_store nodes.
This is an automated email from the git hooks/post-receive script.
nickm pushed a commit to branch main in repository torspec.
commit b7aeadeec6bf5e789912ad30615adcdd955cf71a Author: gabi-250 gabi@torproject.org AuthorDate: Wed Feb 8 16:35:02 2023 +0000
Grammar fix --- rend-spec-v3.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 9700dfb..c1d9a2a 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -604,7 +604,7 @@ Table of contents:
Introduction point authentication key -- A short-term signing keypair used to identify a hidden service's session at a given - introduction point. The service makes a fresh keypair is made for each + introduction point. The service makes a fresh keypair for each introduction point; these are used to sign the request that a hidden service host makes when establishing an introduction point, so that clients who know the public component of this key
This is an automated email from the git hooks/post-receive script.
nickm pushed a commit to branch main in repository torspec.
commit 4234d9325913a0c2ab54a86f2108b3fe99551035 Merge: b7aeade 71d7e71 Author: Nick Mathewson nickm@torproject.org AuthorDate: Wed Feb 8 11:37:35 2023 -0500
Merge remote-tracking branches 'tor-gitlab/mr/114' and 'tor-gitlab/mr/115'
proposals/340-packed-and-fragmented.md | 61 ++++++++++++++++++++++++++++------ rend-spec-v3.txt | 26 ++++++--------- tor-spec.txt | 2 +- 3 files changed, 62 insertions(+), 27 deletions(-)
diff --cc rend-spec-v3.txt index c1d9a2a,672248e..0dc20db --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@@ -1236,12 -1229,11 +1236,13 @@@ Table of contents data of the right size (that's 8 bytes for 'client-id', 16 bytes for 'iv' and 16 bytes for 'encrypted-cookie' all encoded with base64).
- When client authorization is enabled, each "auth-client" line contains - the descriptor cookie encrypted to each individual client. We assume that - each authorized client possesses a pre-shared x25519 keypair - KS/KP_hsc_desc_enc which is used to decrypt the descriptor cookie. + When client authorization is enabled, each "auth-client" line + contains the descriptor cookie `N_hs_desc_enc` encrypted to each + individual client. We assume that each authorized client possesses + a pre-shared x25519 keypair (`KP_hsc_desc_enc`) which is used to + decrypt the descriptor cookie. + + We now describe the descriptor cookie encryption scheme. Here are the relevant keys:
tor-commits@lists.torproject.org
-
gitolite role