diff options
author | Nick Mathewson <nickm@torproject.org> | 2023-02-07 14:51:08 -0500 |
---|---|---|
committer | Nick Mathewson <nickm@torproject.org> | 2023-02-07 14:51:08 -0500 |
commit | da8ecedde5c62d2d48930d8ec09708cd123b2258 (patch) | |
tree | 01cc3901ca32890fd7cb60a9079eb331f89cac5a /rend-spec-v3.txt | |
parent | ca400dc9f82f8e644d8c3b834a80a41a68748880 (diff) | |
download | torspec-da8ecedde5c62d2d48930d8ec09708cd123b2258.tar.gz torspec-da8ecedde5c62d2d48930d8ec09708cd123b2258.zip |
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.
Diffstat (limited to 'rend-spec-v3.txt')
-rw-r--r-- | rend-spec-v3.txt | 14 |
1 files changed, 7 insertions, 7 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 |