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: