From da8ecedde5c62d2d48930d8ec09708cd123b2258 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Tue, 7 Feb 2023 14:51:08 -0500 Subject: 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: -- cgit v1.2.3-54-g00ecf