diff options
| -rw-r--r-- | dir-spec.txt | 11 | ||||
| -rw-r--r-- | proposals/324-rtt-congestion-control.txt | 2 | ||||
| -rw-r--r-- | proposals/339-udp-over-tor.md | 72 | ||||
| -rw-r--r-- | rend-spec-v3.txt | 114 | ||||
| -rw-r--r-- | srv-spec.txt | 5 | ||||
| -rw-r--r-- | tor-spec.txt | 65 |
6 files changed, 184 insertions, 85 deletions
diff --git a/dir-spec.txt b/dir-spec.txt index db64b5d..b6a7c8e 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -279,12 +279,13 @@ Table of Contents NL = The ascii LF character (hex value 0x0a). Document ::= (Item | NL)+ - Item ::= KeywordLine Object* - KeywordLine ::= Keyword NL | Keyword WS ArgumentChar+ NL + Item ::= KeywordLine Object? + KeywordLine ::= Keyword (WS Argument)* NL Keyword = KeywordStart KeywordChar* KeywordStart ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' KeywordChar ::= KeywordStart | '-' - ArgumentChar ::= any printing ASCII character except NL. + Argument := ArgumentChar+ + ArgumentChar ::= any graphical printing ASCII character. WS = (SP | TAB)+ Object ::= BeginLine Base64-encoded-data EndLine BeginLine ::= "-----BEGIN " Keyword (" " Keyword)* "-----" NL @@ -2112,7 +2113,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 +2133,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/proposals/324-rtt-congestion-control.txt b/proposals/324-rtt-congestion-control.txt index 952d140..625fab2 100644 --- a/proposals/324-rtt-congestion-control.txt +++ b/proposals/324-rtt-congestion-control.txt @@ -1554,7 +1554,7 @@ These are sorted in order of importance to tune, most important first. - Description: This parameter defines the integer number of 'cc_sendme_inc' multiples of gap allowed between inflight and cwnd, to still declare the cwnd full. - - Range: [0, INT32_MAX] + - Range: [0, INT16_MAX] - Default: 1-2 - Shadow Tuning Results: A value of 0 resulted in a slight loss of performance, and increased diff --git a/proposals/339-udp-over-tor.md b/proposals/339-udp-over-tor.md index 3c1a1d4..5993bdc 100644 --- a/proposals/339-udp-over-tor.md +++ b/proposals/339-udp-over-tor.md @@ -149,6 +149,42 @@ along with extensions to some older relay message types. We note in passing how we could extend these messages to support unconnected UDP sockets in the future. +### Common Format + +We define here a common format for an "address" that is used both in a +CONNECT_UDP and CONNECTED_UDP cell. + +#### Address + +Defines an IP or Hostname address along with its port. This can be seen as the +`ADDRPORT` of a `BEGIN` cell defined in tor-spec.txt but with a different +format. + +``` +/* Address types. + + Note that these are the same as in RESOLVED cells. +*/ +const T_HOSTNAME = 0x00; +const T_IPV4 = 0x04; +const T_IPV6 = 0x06; + +struct address { + u8 type IN [T_IPV4, T_IPV6, T_HOSTNAME]; + u8 len; + union addr[type] with length len { + T_IPV4: u32 ipv4; + T_IPV6: u8 ipv6[16]; + T_HOSTNAME: u8 hostname[]; + }; + u16 port; +} +``` + +The `hostname` follows the RFC1035 for its accepted length that is 63 +characters or less that is a `len` between 0 and 255 (bytes). It should +contain a sequence of nonzero octets as in any nul byte results in a malformed +cell. ### CONNECT_UDP @@ -161,26 +197,13 @@ sockets in the future. struct connect_udp_body { /* As in BEGIN cells. */ u32 flags; - /* Tag for union below. */ - u8 addr_type IN [T_HOSTNAME, T_IPV4, T_IPV6]; - /* Length of the following union */ - u8 addr_len; - /* The address to connect to. */ - union address[addr_type] with length addr_len { - T_IPV4: u32 ipv4; - T_IPV6: u8 ipv6[16]; - T_HOSTNAME: nulterm name - }; - u16 port; + /* Address to connect to. */ + struct address addr; // The rest is ignored. // TODO: Is "the rest is ignored" still a good idea? Look at Rochet's // research. } -/* Address types */ -const T_HOSTNAME = 0x01; -const T_IPV4 = 0x04; -const T_IPV6 = 0x06; /* As in BEGIN cells: these control how hostnames are interpreted. Clients MUST NOT send unrecognized flags; relays MUST ignore them. @@ -191,6 +214,10 @@ const FLAG_IPV4_NOT_OKAY = 0x02; const FLAG_IPV6_PREFERRED = 0x04; ``` +A "hostname" is a DNS hostname that can only contain ascii characters. It is +NOT following the large and broad DNS syntax. These behaves exacly like BEGIN +cell behave with regards to the hostname given. + ### CONNECTED_UDP A CONNECTED_UDP cell sent in response to a CONNECT_UDP cell has the following @@ -208,20 +235,11 @@ struct udp_connected_body { // TODO: Is "the rest is ignored" still a good idea? Look at Rochet's // research. } - -/* Note that this is a subset of the allowable address parts of a CONNECT_UDP - * message */ -struct address { - u8 tag IN [T_IPV4, T_IPV6]; - u8 len; - union addr[tag] with length len { - T_IPV4: u32 ipv4; - T_IPV6: u8 ipv6[16]; - }; - u16 port; -} ``` +Both `our_address` and `their_address` MUST NOT be of type `T_HOSTNAME` else +the cell is considered malformed. + ### DATAGRAM ``` diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 0914c81..a8ac264 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -495,12 +495,21 @@ 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_hs_id. + 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 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 @@ -574,6 +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_hs_id, KS_hs_id. Blinded signing key -- A keypair derived from the identity key, used to sign descriptor signing keys. It changes periodically for @@ -582,6 +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. Descriptor signing key -- A key used to sign hidden service descriptors. This is signed by blinded signing keys. Unlike @@ -589,6 +600,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_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 @@ -599,23 +611,27 @@ 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 + ("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. 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 (KS_onion_ntor, KP_onion_ntor). - (Node) identity key + (Node) identity key (KP_relayid). Symmetric key-like things defined elsewhere: @@ -636,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 @@ -681,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. @@ -704,6 +722,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 @@ -724,10 +743,11 @@ Table of contents: Time periods start at the Unix epoch (Jan 1, 1970), and are computed by taking the number of minutes since the epoch and dividing by the time - period. However, we want our time periods to start at 12:00UTC every day, so - we subtract a "rotation time offset" of 12*60 minutes from the number of - minutes since the epoch, before dividing by the time period (effectively - making "our" epoch start at Jan 1, 1970 12:00UTC). + period. However, we want our time periods to start at a regular offset + from the SRV voting schedule, so we subtract a "rotation time offset" + of 12 voting periods from the number of minutes since the epoch, before + dividing by the time period (effectively making "our" epoch start at Jan + 1, 1970 12:00UTC when the voting period is 1 hour.) Example: If the current time is 2016-04-13 11:15:01 UTC, making the seconds since the epoch 1460546101, and the number of minutes since the epoch @@ -1226,7 +1246,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 @@ -1251,6 +1271,13 @@ Table of contents: discussed in [HS-DESC-SECOND-LAYER] below. The blob is base64 encoded and enclosed in -----BEGIN MESSAGE---- and ----END MESSAGE---- wrappers. + + Compatibility note: The C Tor implementation does not include a final + newline when generating this first-layer-plaintext section; other + implementations MUST accept this section even if it is missing its final + newline. Other implementations MAY generate this section without a final + newline themselves, to avoid being distinguishable from C tor. + 2.5.1.3. Client behavior [FIRST-LAYER-CLIENT-BEHAVIOR] The goal of clients at this stage is to decrypt the "encrypted" field as @@ -1378,22 +1405,48 @@ Table of contents: key of the introduction point Tor node used for the ntor handshake when a client extends to it. + "onion-key" SP KeyType SP key.. NL + + [Any number of times] + + Implementations should accept other types of onion keys using this + syntax (where "KeyType" is some string other than "ntor"); + unrecognized key types should be ignored. + "auth-key" NL certificate NL [Exactly once per introduction point] - The certificate is a proposal 220 certificate wrapped in "-----BEGIN - ED25519 CERT-----" cross-certifying the introduction point - authentication key using the descriptor signing key. The introduction - point authentication key is included in the mandatory signing-key - extension. The certificate type must be [09]. + 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 + the descriptor signing key (`KP_hs_desc_sign`). The + certificate type must be [09], and the signing key extension + is mandatory. + + NOTE: This certificate was originally intended to be + constructed the other way around: the signing and signed keys + are meant to be reversed. However, C tor implemented it + backwards, and other implementations now need to do the same + in order to conform. (Since this section is inside the + descriptor, which is _already_ signed by `KP_hs_desc_sign`, + the verification aspect of this certificate serves no point in + its current form.) "enc-key" SP "ntor" SP key NL [Exactly once per introduction point] The key is a base64 encoded curve25519 public key used to encrypt - the introduction request to service. + the introduction request to service. (`KP_hs_intro_ntor`) + + "enc-key" SP KeyType SP key.. NL + + [Any number of times] + + Implementations should accept other types of onion keys using this + syntax (where "KeyType" is some string other than "ntor"); + unrecognized key types should be ignored. "enc-key-cert" NL certificate NL @@ -1402,13 +1455,22 @@ Table of contents: Cross-certification of the encryption key using the descriptor signing key. - For "ntor" keys, certificate is a proposal 220 certificate wrapped - in "-----BEGIN ED25519 CERT-----" armor, cross-certifying the - descriptor signing key with the ed25519 equivalent of a curve25519 - public encryption key derived using the process in proposal 228 - appendix A. The certificate type must be [0B], and the signing-key + 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 + 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 extension is mandatory. + NOTE: As with "auth-key", this certificate was intended to be + 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 + the `enc-key` entry. + "legacy-key" NL key NL [None or at most once per introduction point] @@ -1459,7 +1521,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) @@ -1920,7 +1982,7 @@ Table of contents: and computes: intro_secret_hs_input = EXP(B,x) | 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) ENC_KEY = hs_keys[0:S_KEY_LEN] MAC_KEY = hs_keys[S_KEY_LEN:S_KEY_LEN+MAC_KEY_LEN] @@ -1974,7 +2036,7 @@ Table of contents: introduction point encryption key 'b' to compute: 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/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 diff --git a/tor-spec.txt b/tor-spec.txt index d5305f2..e522135 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -94,9 +94,11 @@ see tor-design.pdf. 0.1. Notation and encoding - PK -- a public key. - SK -- 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. a|b -- concatenation of 'a' and 'b'. @@ -121,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. @@ -178,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. @@ -194,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 @@ -230,14 +232,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 +252,35 @@ 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_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_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_ed, KS_link_ed. - 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_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_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 @@ -530,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) @@ -1179,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 @@ -1187,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 @@ -1258,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: @@ -1270,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 |