[torspec] branch main updated (635270c -> f16803f)

List overview All Threads
Download

newer

older

...

gitolite role

19 Jan 2023 19 Jan '23

3:21 p.m.

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a change to branch main in repository torspec.

from 635270c Merge branch 'tor-gitlab/mr/103' new 5e9d6fc Introduce names for the principal relay keys new 4af1697 Introduce names for the principal rendezvous keys new e3dd512 Say that HS identity keys are not the same as relay identity keys new b631068 rend-spec: Clarify and slightly reword credential explanation new 3c68fd5 Give a formal name to shared_random_value new 1d5ba4f Uwe formal notation for credential and subcredential new 9091995 Use _ed rather than _ntor for ed25519 keys new 0dd6146 Make all HS key names contain _hs_ new 7bc2766 K_hs_intro_ntor: rename from K_hs_intro_enc new a4e3bdb Properly say KS_onion_ed is a keypair new fc42e97 Properly say KP_relayid rather than K_relayid new 3bdb237 Revert "Say that HS identity keys are not the same as relay identity keys" new e1ee12e Document that keypairs should not double up roles, with example new c1aa867 Rename KP_hs_intro_auth to KP_hs_intro_tid new 5f3e97c Provide names for HS client authentication keys new 025d469 Rename onion keys back to K*_onion_ntor new 9ebadaa tor-spec: Change PK/SK to KP/KS in definition section new dc4b593 tor-spec: Clarifiy KP/KS in definition section new f16803f tor-spec: Change KP to KP throughout

The 19 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: dir-spec.txt | 4 ++-- rend-spec-v3.txt | 41 +++++++++++++++++++++++++---------- srv-spec.txt | 5 +++-- tor-spec.txt | 65 +++++++++++++++++++++++++++++++++++--------------------- 4 files changed, 76 insertions(+), 39 deletions(-)

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

Show replies by date

gitolite role

19 Jan 19 Jan

3:21 p.m.

New subject: [torspec] 01/19: Introduce names for the principal relay keys

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit 5e9d6fcce64550f20e85a36323179e04f1b269d4 Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Tue Jan 17 13:06:08 2023 +0000

Introduce names for the principal relay keys --- tor-spec.txt | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/tor-spec.txt b/tor-spec.txt index d5305f2..d967a8e 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -230,14 +230,17 @@ see tor-design.pdf.

- A long-term signing-only "Identity key" used to sign documents and certificates, and used to establish relay identity. + KP_relayid_rsa, KS_relayid_rsa. - A medium-term TAP "Onion key" used to decrypt onion skins when accepting circuit extend attempts. (See 5.1.) Old keys MUST be accepted for a while after they are no 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_tap, KS_onion_tap. - A short-term "Connection key" used to negotiate TLS connections. Tor implementations MAY rotate this key as often as they like, and SHOULD rotate this key at least once a day. + KP_conn_tls, KS_conn_tls.

This is Curve25519 key:

@@ -247,23 +250,30 @@ 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.

These are Ed25519 keys:

- A long-term "master identity" key. This key never changes; it is used only to sign the "signing" key below. It may be kept offline. + KP_relayid_ntor, KS_relayid_ntor. - A medium-term "signing" key. This key is signed by the master identity key, and must be kept online. A new one should be generated periodically. It signs nearly everything else. + KP_relaysign_ntor, KS_relaysign_ntor. - A short-term "link authentication" key, used to authenticate the link handshake: see section 4 below. This key is signed by the "signing" key, and should be regenerated frequently. + KP_link_ntor, KS_link_ntor.

- The RSA identity key and Ed25519 master identity key together identify a - router uniquely. Once a router has used an Ed25519 master identity key - together with a given RSA identity key, neither of those keys may ever be - used with a different key. + KP_relayid_* together identify a router uniquely. Once a router + has used a KP_relayid_ntor (an Ed25519 master identity key) + together with a given KP_relayid_rsa (RSA identity key), neither of + those keys may ever be used with a different key. + + We write KP_relayid to refer to a key which is either + KP_relayid_rsa or KP_relayid_ntor.

2. Connections

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 02/19: Introduce names for the principal rendezvous keys

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit 4af1697371aa251cc412c02b35be26273b8ed92a Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Tue Jan 17 13:16:48 2023 +0000

Introduce names for the principal rendezvous keys --- rend-spec-v3.txt | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 0914c81..29c94d6 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -574,6 +574,8 @@ Table of contents: to generate blinded signing keys as described in [KEYBLIND] and [SUBCRED]. The public key is encoded in the ".onion" address according to [NAMING]. + KP_hsid, KS_hsid. +

Blinded signing key -- A keypair derived from the identity key, used to sign descriptor signing keys. It changes periodically for @@ -582,6 +584,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.

Descriptor signing key -- A key used to sign hidden service descriptors. This is signed by blinded signing keys. Unlike @@ -589,6 +592,7 @@ Table of contents: of this key must be stored online by hidden service hosts. The public part of this key is included in the unencrypted section of HS descriptors (see [DESC-OUTER]). + KP_desc_sign, KS_desc_sign.

Introduction point authentication key -- A short-term signing keypair used to identify a hidden service to a given @@ -599,23 +603,26 @@ 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_intro_auth, KS_intro_auth.

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. + K_intro_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.

Public/private keypairs defined elsewhere:

- Onion key -- Short-term encryption keypair + Onion key -- Short-term encryption keypair (K_onion_ntor).

- (Node) identity key + (Node) identity key (K_relayid).

Symmetric key-like things defined elsewhere:

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 03/19: Say that HS identity keys are not the same as relay identity keys

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit e3dd51226418f13d13eb86de58d955787fa3709e Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Tue Jan 17 13:17:06 2023 +0000

Say that HS identity keys are not the same as relay identity keys --- rend-spec-v3.txt | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 29c94d6..d72c36f 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -576,6 +576,8 @@ Table of contents: address according to [NAMING]. KP_hsid, KS_hsid.

+ For services which run on a relay, this key SHOULD NOT be the + same as the Tor instance's KP_relayid_ntor.

Blinded signing key -- A keypair derived from the identity key, used to sign descriptor signing keys. It changes periodically for

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 04/19: rend-spec: Clarify and slightly reword credential explanation

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit b63106887099ad4bbfcd21623ab29a4b9583048c Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Tue Jan 17 13:21:26 2023 +0000

rend-spec: Clarify and slightly reword credential explanation

Introduce the credential and subcredential before we use them. Talk about the public identity key rather than the credential, when we can. --- rend-spec-v3.txt | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index d72c36f..dacdaa9 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -495,12 +495,19 @@ Table of contents: hidden service descriptors are not signed with the services' public keys directly. Instead, we use a key-blinding system [KEYBLIND] to create a new key-of-the-day for each hidden service. Any client that - knows the hidden service's credential can derive these blinded + knows the hidden service's public identity key can derive these blinded signing keys for a given period. It should be impossible to derive - the blinded signing key lacking that credential. + the blinded signing key lacking that knowledge. + + This is achieved using two nonces: + + * A "credential", derived from the public identity key KP_hsid. + + * A "subcredential", derived from the credential N_hs_cred + and information which various with the current time period.

The body of each descriptor is also encrypted with a key derived from - the credential. + the public signing key.

To avoid a "thundering herd" problem where every service generates and uploads a new descriptor at the start of each period, each

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 05/19: Give a formal name to shared_random_value

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit 3c68fd57e11467978f1ca7c8bad1c4c58d58685f Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Tue Jan 17 13:32:02 2023 +0000

Give a formal name to shared_random_value --- dir-spec.txt | 4 ++-- rend-spec-v3.txt | 1 + srv-spec.txt | 5 +++-- 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/dir-spec.txt b/dir-spec.txt index db64b5d..d6dae43 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2112,7 +2112,7 @@ Table of Contents NumReveals ::= An integer greater or equal to 0. Value ::= Base64-encoded-data

- The shared random value that was generated during the second-to-last + The shared_random_value that was generated during the second-to-last shared randomness protocol run. For example, if this document was created on the 5th of November, this field carries the shared random value generated during the protocol run of the 3rd of November. @@ -2132,7 +2132,7 @@ Table of Contents NumReveals ::= An integer greater or equal to 0. Value ::= Base64-encoded-data

- The shared random value that was generated during the latest shared + The shared_random_value that was generated during the latest shared randomness protocol run. For example, if this document was created on the 5th of November, this field carries the shared random value generated during the protocol run of the 4th of November diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index dacdaa9..c6586ce 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -720,6 +720,7 @@ Table of contents: * the daily subcredential, * the hidden service directories' public keys, * a shared random value that changes in each time period, + shared_random_value. * a set of network-wide networkstatus consensus parameters. (Consensus parameters are integer values voted on by authorities and published in the consensus documents, described in diff --git a/srv-spec.txt b/srv-spec.txt index a68ef3e..f768b73 100644 --- a/srv-spec.txt +++ b/srv-spec.txt @@ -98,8 +98,9 @@ Tor works. This text used to be proposal 250-commit-reveal-consensus.txt. 2.1. Ten thousand feet view of the protocol

Our commit-and-reveal protocol aims to produce a fresh shared random value - every day at 00:00UTC. The final fresh random value is embedded in the - consensus document at that time. + (denoted shared_random_value here and elsewhere) every day at 00:00UTC. The + final fresh random value is embedded in the consensus document at that + time.

Our protocol has two phases and uses the hourly voting procedure of Tor. Each phase lasts 12 hours, which means that 12 voting rounds happen in

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 06/19: Uwe formal notation for credential and subcredential

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit 1d5ba4f51a302992b9c29a2aca1c8f6bf4f29872 Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Tue Jan 17 13:25:39 2023 +0000

Uwe formal notation for credential and subcredential

In particular, give these formal names which contain "hs" (since they are part of the hidden service protocol, and not any other kind of authentication or authorisation scheme), and "N" to indicate that they are hash-generated nonces, not passwords.

Change the references in the formulae, which it really seems to me ought to refer to the formal names. --- rend-spec-v3.txt | 14 ++++++++------ tor-spec.txt | 2 ++ 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index c6586ce..bc565fa 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -502,9 +502,11 @@ Table of contents: This is achieved using two nonces:

* A "credential", derived from the public identity key KP_hsid. + N_hs_cred.

* A "subcredential", derived from the credential N_hs_cred and information which various with the current time period. + N_hs_subcred.

The body of each descriptor is also encrypted with a key derived from the public signing key. @@ -697,11 +699,11 @@ Table of contents:

The subcredential for a period is derived as:

- subcredential = H("subcredential" | credential | blinded-public-key). + N_hs_subcred = H("subcredential" | N_hs_cred | blinded-public-key).

In the above formula, credential corresponds to:

- credential = H("credential" | public-identity-key) + N_hs_cred = H("credential" | public-identity-key)

where public-identity-key is the public identity master key of the hidden service. @@ -1243,7 +1245,7 @@ Table of contents: And here is what the hidden service computes:

SECRET_SEED = x25519(hs_y, client_X) - KEYS = KDF(subcredential | SECRET_SEED, 40) + KEYS = KDF(N_hs_subcred | SECRET_SEED, 40) CLIENT-ID = fist 8 bytes of KEYS COOKIE-KEY = last 32 bytes of KEYS

@@ -1476,7 +1478,7 @@ Table of contents: descriptor even if the content of the descriptor hasn't changed. (So that we don't leak whether the intro point list etc. changed)

- secret_input = SECRET_DATA | subcredential | INT_8(revision_counter) + secret_input = SECRET_DATA | N_hs_subcred | INT_8(revision_counter)

keys = KDF(secret_input | salt | STRING_CONSTANT, S_KEY_LEN + S_IV_LEN + MAC_KEY_LEN)

@@ -1937,7 +1939,7 @@ Table of contents: and computes:

intro_secret_hs_input = EXP(X,b) | AUTH_KEY | X | B | PROTOID - info = m_hsexpand | subcredential + info = m_hsexpand | N_hs_subcred hs_keys = KDF(intro_secret_hs_input | t_hsenc | info, S_KEY_LEN+MAC_LEN) HS_DEC_KEY = hs_keys[0:S_KEY_LEN] HS_MAC_KEY = hs_keys[S_KEY_LEN:S_KEY_LEN+MAC_KEY_LEN] diff --git a/tor-spec.txt b/tor-spec.txt index d967a8e..6654e0e 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -97,6 +97,8 @@ see tor-design.pdf. PK -- a public key. SK -- a private key. K -- a key for a symmetric cipher. + N -- a "nonce", a random value, usually deterministically chosen + from other inputs using hashing.

a|b -- concatenation of 'a' and 'b'.

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 07/19: Use _ed rather than _ntor for ed25519 keys

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit 90919950d131cb9a0b6bae4778822d0c565757eb Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Tue Jan 17 18:10:51 2023 +0000

Use _ed rather than _ntor for ed25519 keys

Even the ones that are actually ntor. Perhaps that's wrong and those should be ntor? Personally I like it this way. --- rend-spec-v3.txt | 4 ++-- tor-spec.txt | 12 ++++++------ 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index bc565fa..4d598cc 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -586,7 +586,7 @@ Table of contents: KP_hsid, KS_hsid.

For services which run on a relay, this key SHOULD NOT be the - same as the Tor instance's KP_relayid_ntor. + same as the Tor instance's KP_relayid_ed.

Blinded signing key -- A keypair derived from the identity key, used to sign descriptor signing keys. It changes periodically for @@ -631,7 +631,7 @@ Table of contents:

Public/private keypairs defined elsewhere:

- Onion key -- Short-term encryption keypair (K_onion_ntor). + Onion key -- Short-term encryption keypair (K_onion_ed).

(Node) identity key (K_relayid).

diff --git a/tor-spec.txt b/tor-spec.txt index 6654e0e..c21fe49 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -252,30 +252,30 @@ 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_onion_ed, KS_onion_ed.

These are Ed25519 keys:

- A long-term "master identity" key. This key never changes; it is used only to sign the "signing" key below. It may be kept offline. - KP_relayid_ntor, KS_relayid_ntor. + KP_relayid_ed, KS_relayid_ed. - A medium-term "signing" key. This key is signed by the master identity key, and must be kept online. A new one should be generated periodically. It signs nearly everything else. - KP_relaysign_ntor, KS_relaysign_ntor. + KP_relaysign_ed, KS_relaysign_ed. - A short-term "link authentication" key, used to authenticate the link handshake: see section 4 below. This key is signed by the "signing" key, and should be regenerated frequently. - KP_link_ntor, KS_link_ntor. + KP_link_ed, KS_link_ed.

KP_relayid_* together identify a router uniquely. Once a router - has used a KP_relayid_ntor (an Ed25519 master identity key) + has used a KP_relayid_ed (an Ed25519 master identity key) together with a given KP_relayid_rsa (RSA identity key), neither of those keys may ever be used with a different key.

We write KP_relayid to refer to a key which is either - KP_relayid_rsa or KP_relayid_ntor. + KP_relayid_rsa or KP_relayid_ed.

2. Connections

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 08/19: Make all HS key names contain _hs_

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit 0dd614681cd70e6560002e243090302fad3e5363 Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Tue Jan 17 18:14:42 2023 +0000

Make all HS key names contain _hs_

Suggested here https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/105#note_286... --- rend-spec-v3.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 4d598cc..321c20a 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -501,7 +501,7 @@ Table of contents:

This is achieved using two nonces:

- * A "credential", derived from the public identity key KP_hsid. + * A "credential", derived from the public identity key KP_hs_id. N_hs_cred.

* A "subcredential", derived from the credential N_hs_cred @@ -583,7 +583,7 @@ Table of contents: to generate blinded signing keys as described in [KEYBLIND] and [SUBCRED]. The public key is encoded in the ".onion" address according to [NAMING]. - KP_hsid, KS_hsid. + KP_hs_id, KS_hs_id.

For services which run on a relay, this key SHOULD NOT be the same as the Tor instance's KP_relayid_ed. @@ -603,7 +603,7 @@ Table of contents: of this key must be stored online by hidden service hosts. The public part of this key is included in the unencrypted section of HS descriptors (see [DESC-OUTER]). - KP_desc_sign, KS_desc_sign. + 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 @@ -614,13 +614,13 @@ 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_intro_auth, KS_intro_auth. + KP_hs_intro_auth, KS_hs_intro_auth.

Symmetric keys defined in this document:

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 09/19: K_hs_intro_ntor: rename from K_hs_intro_enc

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit 7bc2766bad09ece0c18039418143169efe27c02f Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Tue Jan 17 18:16:08 2023 +0000

K_hs_intro_ntor: rename from K_hs_intro_enc

Prompted by https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/105#note_286... --- 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 321c20a..879da3f 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -620,7 +620,7 @@ Table of contents: 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. - K_hs_intro_enc. + KP_hs_intro_ntor, KS_hs_intro_ntor.

Symmetric keys defined in this document:

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 10/19: Properly say KS_onion_ed is a keypair

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit a4e3bdbe6e5a91683561b0ef7a5b2ddc1e851452 Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Tue Jan 17 18:17:15 2023 +0000

Properly say KS_onion_ed is a keypair --- 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 879da3f..22034a2 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -631,7 +631,7 @@ Table of contents:

Public/private keypairs defined elsewhere:

- Onion key -- Short-term encryption keypair (K_onion_ed). + Onion key -- Short-term encryption keypair (KS_onion_ed, KP_onion_ed).

(Node) identity key (K_relayid).

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 11/19: Properly say KP_relayid rather than K_relayid

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit fc42e97dd329206764c1388037f2e8365aca9ef8 Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Tue Jan 17 18:18:24 2023 +0000

Properly say KP_relayid rather than K_relayid --- 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 22034a2..5d17075 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -633,7 +633,7 @@ Table of contents:

Onion key -- Short-term encryption keypair (KS_onion_ed, KP_onion_ed).

- (Node) identity key (K_relayid). + (Node) identity key (KP_relayid).

Symmetric key-like things defined elsewhere:

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 12/19: Revert "Say that HS identity keys are not the same as relay identity keys"

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit 3bdb23706aeae16e1aae6afe081185ca77ebdc34 Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Tue Jan 17 18:20:34 2023 +0000

Revert "Say that HS identity keys are not the same as relay identity keys"

This reverts commit 81c1be641557d1cd3fb6d9195de08e9f411be517. --- rend-spec-v3.txt | 3 --- 1 file changed, 3 deletions(-)

diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 5d17075..196b859 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -585,9 +585,6 @@ Table of contents: address according to [NAMING]. KP_hs_id, KS_hs_id.

- For services which run on a relay, this key SHOULD NOT be the - same as the Tor instance's KP_relayid_ed. - Blinded signing key -- A keypair derived from the identity key, used to sign descriptor signing keys. It changes periodically for each service. Clients who know a 'credential' consisting of the

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 13/19: Document that keypairs should not double up roles, with example

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit e1ee12e8107dd91599019eea84600666763e478c Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Tue Jan 17 18:22:08 2023 +0000

Document that keypairs should not double up roles, with example --- tor-spec.txt | 5 +++++ 1 file changed, 5 insertions(+)

diff --git a/tor-spec.txt b/tor-spec.txt index c21fe49..8179a9d 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -277,6 +277,11 @@ see tor-design.pdf. We write KP_relayid to refer to a key which is either KP_relayid_rsa or KP_relayid_ed.

+ The same key or keypair should never be used for separate roles within + the Tor protocol suite, unless specifically stated. For example, + a relay's identity keys K_relayid should not also be used as the + identity keypair for a hidden service K_hs_id (see rend-spec-v3.txt). + 2. Connections

Connections between two Tor relays, or between a client and a relay,

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 14/19: Rename KP_hs_intro_auth to KP_hs_intro_tid

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit c1aa86781922a10d1a3ef11f9b87999d228f2df5 Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Wed Jan 18 15:51:38 2023 +0000

Rename KP_hs_intro_auth to KP_hs_intro_tid --- rend-spec-v3.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 196b859..406c09a 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -611,7 +611,8 @@ 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_auth, KS_hs_intro_auth. + KP_hs_intro_tid, KS_hs_intro_tid + ("hidden service introduction point temporary id").

Introduction point encryption key -- A short-term encryption keypair used when establishing connections via an introduction

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 15/19: Provide names for HS client authentication keys

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit 5f3e97cfa13c4c86e507d376fc21e9867466b785 Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Wed Jan 18 15:58:03 2023 +0000

Provide names for HS client authentication keys --- rend-spec-v3.txt | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 406c09a..5f0ead1 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -652,11 +652,13 @@ Table of contents:

- An x25519 keypair used to compute decryption keys that allow the client to decrypt the hidden service descriptor. See [HS-DESC-ENC]. + KP_hsc_desc_enc, KS_hsd_desc_enc.

- An ed25519 keypair which allows the client to compute signatures which prove to the hidden service that the client is authorized. These signatures are inserted into the INTRODUCE1 cell, and without them the introduction to the hidden service cannot be completed. See [INTRO-AUTH]. + KP_hsc_intro_auth, KS_hsc_intro_auth.

The right way to exchange these keys is to have the client generate keys and send the corresponding public keys to the hidden service out-of-band. An

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 16/19: Rename onion keys back to K*_onion_ntor

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit 025d4698375d774f4b8f0685a2956738cd4ae4e8 Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Wed Jan 18 16:00:51 2023 +0000

Rename onion keys back to K*_onion_ntor

As per review comments --- rend-spec-v3.txt | 2 +- tor-spec.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 5f0ead1..278c1fa 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -629,7 +629,7 @@ Table of contents:

Public/private keypairs defined elsewhere:

- Onion key -- Short-term encryption keypair (KS_onion_ed, KP_onion_ed). + Onion key -- Short-term encryption keypair (KS_onion_ntor, KP_onion_ntor).

(Node) identity key (KP_relayid).

diff --git a/tor-spec.txt b/tor-spec.txt index 8179a9d..e407f3f 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_ed, KS_onion_ed. + KP_onion_ntor, KS_onion_ntor.

These are Ed25519 keys:

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 17/19: tor-spec: Change PK/SK to KP/KS in definition section

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit 9ebadaa2afd27a3fe0774ee4a214e5990c024c50 Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Thu Jan 19 14:23:56 2023 +0000

tor-spec: Change PK/SK to KP/KS in definition section --- tor-spec.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tor-spec.txt b/tor-spec.txt index e407f3f..7db1cb2 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -94,8 +94,8 @@ see tor-design.pdf.

0.1. Notation and encoding

- PK -- a public key. - SK -- a private key. + KP -- a public key. + KS -- a private key. K -- a key for a symmetric cipher. N -- a "nonce", a random value, usually deterministically chosen from other inputs using hashing.

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 18/19: tor-spec: Clarifiy KP/KS in definition section

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit dc4b593ce594440de8838898daff71c68a7c68fd Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Thu Jan 19 14:24:17 2023 +0000

tor-spec: Clarifiy KP/KS in definition section --- tor-spec.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tor-spec.txt b/tor-spec.txt index 7db1cb2..cd95d79 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -94,8 +94,8 @@ see tor-design.pdf.

0.1. Notation and encoding

- KP -- a public key. - KS -- a private key. + KP -- a public key for an asymmetric cipher. + KS -- a private key for an asymmetric cipher. K -- a key for a symmetric cipher. N -- a "nonce", a random value, usually deterministically chosen from other inputs using hashing.

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

gitolite role

3:21 p.m.

New subject: [torspec] 19/19: tor-spec: Change KP to KP throughout

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main in repository torspec.

commit f16803f6f93680f41f72bae29cf9dbef3962f94d Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Thu Jan 19 14:24:27 2023 +0000

tor-spec: Change KP to KP throughout

Emacs's idea of s/\bPK\b/KP/ --- tor-spec.txt | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/tor-spec.txt b/tor-spec.txt index cd95d79..e522135 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -123,10 +123,10 @@ see tor-design.pdf.

KEY_LEN -- the length of the stream cipher's key, in bytes.

- PK_ENC_LEN -- the length of a public-key encrypted message, in bytes. - PK_PAD_LEN -- the number of bytes added in padding for public-key + KP_ENC_LEN -- the length of a public-key encrypted message, in bytes. + KP_PAD_LEN -- the number of bytes added in padding for public-key encryption, in bytes. (The largest number of bytes that can be encrypted - in a single public-key operation is therefore PK_ENC_LEN-PK_PAD_LEN.) + in a single public-key operation is therefore KP_ENC_LEN-KP_PAD_LEN.)

DH_LEN -- the number of bytes used to represent a member of the Diffie-Hellman group. @@ -180,7 +180,7 @@ see tor-design.pdf.

KEY_LEN=16. DH_LEN=128; DH_SEC_LEN=40. - PK_ENC_LEN=128; PK_PAD_LEN=42. + KP_ENC_LEN=128; KP_PAD_LEN=42. HASH_LEN=20.

We also use SHA256 and SHA3-256 in some places. @@ -196,14 +196,14 @@ see tor-design.pdf. 0.4. A bad hybrid encryption algorithm, for legacy purposes.

Some specifications will refer to the "legacy hybrid encryption" of a - byte sequence M with a public key PK. It is computed as follows: + byte sequence M with a public key KP. It is computed as follows:

- 1. If the length of M is no more than PK_ENC_LEN-PK_PAD_LEN, - pad and encrypt M with PK. + 1. If the length of M is no more than KP_ENC_LEN-KP_PAD_LEN, + pad and encrypt M with KP. 2. Otherwise, generate a KEY_LEN byte random key K. - Let M1 = the first PK_ENC_LEN-PK_PAD_LEN-KEY_LEN bytes of M, + Let M1 = the first KP_ENC_LEN-KP_PAD_LEN-KEY_LEN bytes of M, and let M2 = the rest of M. - Pad and encrypt K|M1 with PK. Encrypt M2 with our stream cipher, + Pad and encrypt K|M1 with KP. Encrypt M2 with our stream cipher, using the key K. Concatenate these encrypted values.

Note that this "hybrid encryption" approach does not prevent @@ -547,8 +547,8 @@ see tor-design.pdf. 2 -- CREATED (Acknowledge create) (See Sec 5.1) 3 -- RELAY (End-to-end data) (See Sec 5.5 and 6) 4 -- DESTROY (Stop using a circuit) (See Sec 5.4) - 5 -- CREATE_FAST (Create a circuit, no PK) (See Sec 5.1) - 6 -- CREATED_FAST (Circuit created, no PK) (See Sec 5.1) + 5 -- CREATE_FAST (Create a circuit, no KP) (See Sec 5.1) + 6 -- CREATED_FAST (Circuit created, no KP) (See Sec 5.1) 8 -- NETINFO (Time and address info) (See Sec 4.5) 9 -- RELAY_EARLY (End-to-end data; limited)(See Sec 5.6) 10 -- CREATE2 (Extended CREATE cell) (See Sec 5.1) @@ -1196,7 +1196,7 @@ see tor-design.pdf. not very good. (See Goldberg's "On the Security of the Tor Authentication Protocol".)

- Define TAP_C_HANDSHAKE_LEN as DH_LEN+KEY_LEN+PK_PAD_LEN. + Define TAP_C_HANDSHAKE_LEN as DH_LEN+KEY_LEN+KP_PAD_LEN. Define TAP_S_HANDSHAKE_LEN as DH_LEN+HASH_LEN.

The payload for a CREATE cell is an 'onion skin', which consists of @@ -1204,12 +1204,12 @@ see tor-design.pdf. value is encrypted using the "legacy hybrid encryption" algorithm (see 0.4 above) to the server's onion key, giving a client handshake:

- PK-encrypted: - Padding [PK_PAD_LEN bytes] + KP-encrypted: + Padding [KP_PAD_LEN bytes] Symmetric key [KEY_LEN bytes] - First part of g^x [PK_ENC_LEN-PK_PAD_LEN-KEY_LEN bytes] + First part of g^x [KP_ENC_LEN-KP_PAD_LEN-KEY_LEN bytes] Symmetrically encrypted: - Second part of g^x [DH_LEN-(PK_ENC_LEN-PK_PAD_LEN-KEY_LEN) + Second part of g^x [DH_LEN-(KP_ENC_LEN-KP_PAD_LEN-KEY_LEN) bytes]

The payload for a CREATED cell, or the relay payload for an @@ -1275,7 +1275,7 @@ see tor-design.pdf.

NODEID Server identity digest [ID_LENGTH bytes] KEYID KEYID(B) [H_LENGTH bytes] - CLIENT_PK X [G_LENGTH bytes] + CLIENT_KP X [G_LENGTH bytes]

The server generates a keypair of y,Y = KEYGEN(), and uses its ntor private key 'b' to compute: @@ -1287,7 +1287,7 @@ see tor-design.pdf.

The server's handshake reply is:

- SERVER_PK Y [G_LENGTH bytes] + SERVER_KP Y [G_LENGTH bytes] AUTH H(auth_input, t_mac) [H_LENGTH bytes]

The client then checks Y is in G^* [see NOTE below], and computes

-- To stop receiving notification emails like this one, please contact the administrator of this repository.

707

Age (days ago)

707

Last active (days ago)

tor-commits@lists.torproject.org

19 comments

1 participants

tags (0)

participants (1)

gitolite role