March 2013 - tor-commits - lists.torproject.org

[stem/master] Providing default ipv6-policy entries
by atagar＠torproject.org 14 Mar '13

14 Mar '13

commit 0ce65a43d68291388a5a0f61be2427d78ce7167f Author: Damian Johnson <atagar(a)torproject.org> Date: Thu Mar 14 09:23:21 2013 -0700 Providing default ipv6-policy entries The server descriptor's newish 'ipv6-policy' lines are now documented as being reject-all if it's missing... A missing "ipv6-policy" line is equivalent to "ipv6-policy reject 1-65535". https://gitweb.torproject.org/user/nickm/torspec.git/commitdiff/ef5513b1ad3… --- stem/descriptor/server_descriptor.py | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/stem/descriptor/server_descriptor.py b/stem/descriptor/server_descriptor.py index 89795c9..102a660 100644 --- a/stem/descriptor/server_descriptor.py +++ b/stem/descriptor/server_descriptor.py @@ -158,7 +158,7 @@ class ServerDescriptor(stem.descriptor.Descriptor): :var int uptime: uptime when published in seconds :var str contact: contact information :var stem.exit_policy.ExitPolicy exit_policy: **\*** stated exit policy - :var stem.exit_policy.MicroExitPolicy exit_policy_v6: exit policy for IPv6 + :var stem.exit_policy.MicroExitPolicy exit_policy_v6: **\*** exit policy for IPv6 :var list family: **\*** nicknames or fingerprints of declared family :var int average_bandwidth: **\*** average rate it's willing to relay in bytes/s @@ -225,7 +225,7 @@ class ServerDescriptor(stem.descriptor.Descriptor): self.uptime = None self.contact = None self.exit_policy = None - self.exit_policy_v6 = None + self.exit_policy_v6 = stem.exit_policy.MicroExitPolicy("reject 1-65535") self.family = [] self.average_bandwidth = None

1 0

[torspec/master] Merge remote-tracking branch 'asn/bug8403_take2'
by nickm＠torproject.org 14 Mar '13

14 Mar '13

commit bc96a0a220192b6a0d89d3e59c0b10af2751fecf Merge: 17345bb 1648ca6 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Mar 14 12:45:00 2013 -0400 Merge remote-tracking branch 'asn/bug8403_take2' .../xxx-pluggable-transports-through-proxy.txt | 73 ++++++++++---------- 1 files changed, 36 insertions(+), 37 deletions(-)

1 0

[torspec/master] Edit the xxx-pluggable-transports-through-proxy.txt proposal a bit
by nickm＠torproject.org 14 Mar '13

14 Mar '13

commit 1648ca676aa2ae251b6d751fb826470eadc699f3 Author: George Kadianakis <desnacked(a)riseup.net> Date: Thu Mar 14 12:26:32 2013 -0400 Edit the xxx-pluggable-transports-through-proxy.txt proposal a bit --- .../xxx-pluggable-transports-through-proxy.txt | 73 ++++++++++---------- 1 files changed, 36 insertions(+), 37 deletions(-) diff --git a/proposals/ideas/xxx-pluggable-transports-through-proxy.txt b/proposals/ideas/xxx-pluggable-transports-through-proxy.txt index 221c0d1..3fc7754 100644 --- a/proposals/ideas/xxx-pluggable-transports-through-proxy.txt +++ b/proposals/ideas/xxx-pluggable-transports-through-proxy.txt @@ -6,14 +6,14 @@ Status: Draft Overview - Tor introduced Pluggable Transports in proposal 180 Pluggable Transports - for circumvention. - - The problem is that Tor currently cannot use a Pluggable Transport proxy - and a SOCKS proxy at the same time. This has been noticed by users in - #5195, where Tor would be failing saying "Unacceptable option value: - You have configured more than one proxy type". + Tor introduced Pluggable Transports in proposal "180 Pluggable + Transports for circumvention". + The problem is that Tor currently cannot use a pluggable transport + proxy and a normal (SOCKS/HTTP) proxy at the same time. This has + been noticed by users in #5195, where Tor would be failing saying + "Unacceptable option value: You have configured more than one proxy + type". Trivia @@ -21,7 +21,7 @@ Trivia to write a proposal for it if I wanted to hear what he had to say. Nick spoke and I am writing this proposal. -Acknowledgements +Acknowledgments Most of the credit goes to Nick Mathewson for the main idea and the rest of it goes to George Kadianakis for helping me out in writing @@ -29,51 +29,50 @@ Acknowledgements Motivation - After looking at some options we decided to go for this solution solution + After looking at some options we decided to go for this solution since it guarantees backwards compatibility and is not particularly costly to implement. Design overview - When Tor is configured to use both a Pluggable Transport proxy and SOCKS - proxy it should delegate the proxying to the pluggable transport proxy. - - This can be achieved by setting the environment variables for the SOCKS - proxy to that specified inside of the torrc. + When Tor is configured to use both a pluggable transport proxy and a + normal proxy it should delegate the proxying to the pluggable + transport proxy. - When the pluggable transport proxy starts it will first read the environment - variables and if it detects that it should be using a SOCKS proxy make - all it's traffic go through it. Once the pluggable transport proxy has successfully - established a connection to the SOCKS proxy it should notify Tor of it's - success or failure. - When both the SOCKS and the PluggableTransport directives are set Tor - should set the environemnt variable start the pluggabletransport proxy and wait - for it to report back on the SOCKS proxy status. If the pluggable transport - reports back a failure or it does not report back at all (maybe because - it is an outdated version), Tor should notify the user of the failure - and exit with an error. + This can be achieved by specifying the address and port of the normal + proxy to the pluggable transport proxy using environment variables: + When both a normal proxy and the ClientTransportPlugin directives + are set in the torrc, Tor should put the address of the normal proxy + in an environment variable and start the pluggable transport + proxy. When the pluggable transport proxy starts, it should read the + address of the normal proxy and route all its traffic through it. + After connecting to the normal proxy, the pluggable transport proxy + notifies Tor whether it managed to connect or not. - The environment variables can also contain the credentials for accessing - the proxy. + The environment variables also contain the authentication + credentials for accessing the proxy. Specifications: Tor Pluggable Transport communication - When Tor detects a SOCKS proxy directive and a Pluggable Transport - proxy directive it sets the environment variable: + When Tor detects a normal proxy directive and a pluggable transport + proxy directive, it sets the environment variable: "TOR_PT_PROXY" -- This is the address of the proxy to be used by the pluggable transport proxy. It is in the format: - <proxy_type>://<user_name?>:<password?>@<ip>:<port> + <proxy_type>://[<user_name>][:<password>][@]<ip>:<port> ex. socks5://tor:test1234@198.51.100.1:8000 socks4a://198.51.100.2:8001 + Acceptable values for <proxy_type> are: 'socks5', 'socks4a' and 'http'. + If no <password> can be specified (e.g. in 'socks4a'), it is left out. + + If the pluggable transport proxy detects that the TOR_PT_PROXY + environment variable is set, it attempts connecting to it. On + success it writes to stdout: "PROXY true". + On failure it writes: "PROXY-ERROR <errormessage>". - If the pluggable transport proxy detects that the TOR_PT_PROXY environment - variable is set it attempts connecting to it. On successs it will - write to stdout (as specified in 180-pluggable-transport.txt) - PROXY true. On failure it should write PROXY-ERROR <errormessage>. + If Tor does not read a PROXY line or it reads a PROXY-ERROR line + from its stdout and it is configured to use both a normal proxy and + a pluggable transport it should kill the transport proxy. - If Tor does not read any PROXY line or it reads a PROXY-ERROR line - and it is configured to use both SOCKS and PluggableTransport it should - exit with error.

1 0

[torspec/master] Integrate proposals 200 (create2) and 216 (ntor) into the specs
by nickm＠torproject.org 14 Mar '13

14 Mar '13

commit 2e695e7674ba9f8d5ca712578db6ea67d5be0092 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Mar 13 13:02:18 2013 -0400 Integrate proposals 200 (create2) and 216 (ntor) into the specs --- dir-spec.txt | 28 ++- proposals/200-new-create-and-extend-cells.txt | 3 +- proposals/216-ntor-handshake.txt | 3 +- tor-spec.txt | 314 +++++++++++++++++++++---- 4 files changed, 294 insertions(+), 54 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index c75bbb9..c5ca5c1 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -444,10 +444,20 @@ [Exactly once] - This key is used to encrypt EXTEND cells for this OR. The key MUST be + This key is used to encrypt CREATE cells for this OR. The key MUST be accepted for at least 1 week after any new key is published in a subsequent descriptor. It MUST be 1024 bits. + "ntor-onion-key" base-64-encoded-key + + [At most once] + + A public key used for the ntor circuit extended handshake. It's the + standard encoding of the OR's curve25519 public key, encoded in base + 64. The trailing = sign may be omitted from the base64 encoding. The + key MUST be accepted for at least 1 week after any new key is + published in a subsequent descriptor. + "signing-key" NL a public key in PEM format [Exactly once] @@ -1098,6 +1108,15 @@ The "onion-key" element as specified in 2.1. + "ntor-onion-key" base-64-encoded-key + + [At most once] + + The "ntor-onion-key" element as specified in 2.1. + + (Only included when the vote or consensus is generated with + consensus-method 16 or later.) + "a" SP address ":" portlist NL [Any number] @@ -1836,6 +1855,13 @@ consensuses may include "a" lines listing additional OR ports. + * XXXXX 15 + + * If consensus method 16 or later is used, ntor-onion-key + are included in microdescriptors + + * XXXXX 17 + The signatures at the end of a consensus document are sorted in ascending order by identity digest. diff --git a/proposals/200-new-create-and-extend-cells.txt b/proposals/200-new-create-and-extend-cells.txt index 43025d4..1a556dc 100644 --- a/proposals/200-new-create-and-extend-cells.txt +++ b/proposals/200-new-create-and-extend-cells.txt @@ -2,7 +2,8 @@ Filename: 200-new-create-and-extend-cells.txt Title: Adding new, extensible CREATE, EXTEND, and related cells Author: Robert Ransom Created: 2012-03-22 -Status: Finished +Status: Closed +Implemented-In: 0.2.4.8-alpha History diff --git a/proposals/216-ntor-handshake.txt b/proposals/216-ntor-handshake.txt index 35d4a37..e0c4f63 100644 --- a/proposals/216-ntor-handshake.txt +++ b/proposals/216-ntor-handshake.txt @@ -2,7 +2,8 @@ Filename: 216-ntor-handshake.txt Title: Improved circuit-creation key exchange Author: Nick Mathewson Created: 11-May-2011 -Status: Finished +Status: Closed +Implemented-In: 0.2.4.8-alpha Summary: diff --git a/tor-spec.txt b/tor-spec.txt index f107da5..0c333e7 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -69,6 +69,8 @@ see tor-design.pdf. function. We leave the optional "Label" parameter unset. (For OAEP padding, see ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf) + For the "ntor" handshake, we also use the Curve25519 elliptic curve group. + For Diffie-Hellman, we use a generator (g) of 2. For the modulus (p), we use the 1024-bit safe prime from rfc2409 section 6.2 whose hex representation is: @@ -386,6 +388,8 @@ see tor-design.pdf. 6 -- CREATED_FAST (Circuit created, no PK) (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) + 11 -- CREATED2 (Extended CREATED cell) (See Sec 5.1) Variable-length command values are: 7 -- VERSIONS (Negotiate proto version) (See Sec 4) @@ -647,43 +651,64 @@ see tor-design.pdf. 5.1. CREATE and CREATED cells Users set up circuits incrementally, one hop at a time. To create a - new circuit, OPs send a CREATE cell to the first node, with the - first half of the DH handshake; that node responds with a CREATED - cell with the second half of the DH handshake plus the first 20 bytes - of derivative key data (see section 5.2). To extend a circuit past - the first hop, the OP sends an EXTEND relay cell (see section 5) - which instructs the last node in the circuit to send a CREATE cell - to extend the circuit. - - The payload for a CREATE cell is an 'onion skin', which consists - of the first step of the DH handshake data (also known as g^x). - This value is hybrid-encrypted (see 0.3) to Bob's onion key, giving - an onion-skin of: - PK-encrypted: - Padding [PK_PAD_LEN bytes] - Symmetric key [KEY_LEN bytes] - First part of g^x [PK_ENC_LEN-PK_PAD_LEN-KEY_LEN bytes] - Symmetrically encrypted: - Second part of g^x [DH_LEN-(PK_ENC_LEN-PK_PAD_LEN-KEY_LEN) - bytes] + new circuit, OPs send a CREATE cell to the first node, with the first + half of an authenticated handshake; that node responds with a CREATED + cell with the second half of the handshake. To extend a circuit past + the first hop, the OP sends an EXTEND relay cell (see section 5.1.2) + which instructs the last node in the circuit to send a CREATE cell to + extend the circuit. + + There are two kinds of CREATE and CREATED cells: The older + "CREATE/CREATED" format, and the newer "CREATE2/CREATED2" format. The + newer format is extensible by design; the older one is not. + + A CREATE2 cell contains: + HTYPE (Client Handshake Type) [2 bytes] + HLEN (Client Handshake Data Len) [2 bytes] + HDATA (Client Handshake Data) [HLEN bytes] + + A CREATED2 cell contains: + HLEN (Server Handshake Data Len) [2 bytes] + HDATA (Server Handshake Data) [HLEN bytes] + + Recognized handshake types are: + 0x0000 TAP -- the original Tor handshake; see 5.1.3 + 0x0001 reserved + 0x0002 ntor -- the ntor+curve25519+sha256 handshake; see 5.1.4 + + + The format of a CREATE cell is one of the following: + HDATA (Client Handshake Data) [TAP_C_HANDSHAKE_LEN bytes] + or + HTAG (Client Handshake Type Tag) [16 bytes] + HDATA (Client Handshake Data) [TAP_C_HANDSHAKE_LEN-16 bytes] + + The first format is equivalent to a CREATE2 cell with HTYPE of 'tap' + and length of TAP_C_HANDSHAKE_LEN. The second format is a way to + encapsulate new handshake types into the old CREATE cell format for + migration. See 5.1.2.1 below. Recognized HTAG values are: + + ntor -- 'ntorNTORntorNTOR' + + The format of a CREATED cell is: + HDATA (Server Handshake Data) [TAP_S_HANDSHAKE_LEN bytes] + It's equivalent to a CREATED2 cell with length of and length of + TAP_S_HANDSHAKE_LEN. - The relay payload for an EXTEND relay cell consists of: - Address [4 bytes] - Port [2 bytes] - Onion skin [DH_LEN+KEY_LEN+PK_PAD_LEN bytes] - Identity fingerprint [HASH_LEN bytes] + As usual with DH, x and y MUST be generated randomly. - The port and address field denote the IPv4 address and port of the next - onion router in the circuit; the public key hash is the hash of the PKCS#1 - ASN1 encoding of the next onion router's identity (signing) key. (See 0.3 - above.) Including this hash allows the extending OR verify that it is - indeed connected to the correct target OR, and prevents certain - man-in-the-middle attacks. + In general, clients SHOULD use CREATE whenever they are using the TAP + handshake, and CREATE2 otherwise. Clients SHOULD NOT send the + second format of CREATE cells (the one with the handshake type tag) + to a server directly. - The payload for a CREATED cell, or the relay payload for an - EXTENDED cell, contains: - DH data (g^y) [DH_LEN bytes] - Derivative key data (KH) [HASH_LEN bytes] <see 5.2 below> + Servers always reply to a successful CREATE with a CREATED, and to a + successful CREATE2 with a CREATED2. On failure, a server sends a + DESTROY cell to tear down the circuit. + + [CREATE2 is handled by Tor 0.2.4.7-alpha and later.] + +5.1.1. Choosing circuit IDs in create cells The CircID for a CREATE cell is an arbitrarily chosen nonzero 2-byte integer, selected by the node (OP or OR) that sends the CREATE cell. @@ -692,15 +717,183 @@ see tor-design.pdf. on the ORs' public identity keys: if the sending node has a lower key, it chooses a CircID with an MSB of 0; otherwise, it chooses a CircID with an MSB of 1. + [XXXX fix this when documenting link protocol 4.] (An OP with no public key MAY choose any CircID it wishes, since an OP never needs to process a CREATE cell.) + [XXXX fix this when documenting link protocol 4.] Public keys are compared numerically by modulus. - As usual with DH, x and y MUST be generated randomly. +5.1.2. EXTEND and EXTENDED cells + + To extend an existing circuit, the client sends a EXTEND or EXTENDED2 + relay cell to the last node in the circuit. + + An EXTEND2 cell's relay payload contains: + NSPEC (Number of link specifiers) [1 byte] + NSPEC times: + LSTYPE (Link specifier type) [1 byte] + LSLEN (Link specifier length) [1 byte] + LSPEC (Link specifier) [LSLEN bytes] + HTYPE (Client Handshake Type) [2 bytes] + HLEN (Client Handshake Data Len) [2 bytes] + HDATA (Client Handshake Data) [HLEN bytes] + + Link specifiers describe the next node in the circuit and how to + connect to it. Recognized specifiers are: + [00] TLS-over-TCP, IPv4 address + A four-byte IPv4 address plus two-byte ORPort + [01] TLS-over-TCP, IPv6 address + A sixteen-byte IPv6 address plus two-byte ORPort + [02] Legacy identity + A 20-byte SHA1 identity fingerprint. At most one may be listed. + + Nodes MUST ignore unrecognized specifiers, and MUST accept multiple + instances of specifiers other than 'legacy identity'. -5.1.1. CREATE_FAST/CREATED_FAST cells + The relay payload for an EXTEND relay cell consists of: + Address [4 bytes] + Port [2 bytes] + Onion skin [TAP_C_HANDSHAKE_LEN bytes] + Identity fingerprint [HASH_LEN bytes] + + The "legacy identity" and "identity fingerprint fields are the SHA1 + hash of the PKCS#1 ASN1 encoding of the next onion router's identity + (signing) key. (See 0.3 above.) Including this hash allows the + extending OR verify that it is indeed connected to the correct target + OR, and prevents certain man-in-the-middle attacks. + + The payload of an EXTENDED cell is the same as the payload of a + CREATED cell. + + The payload of an EXTENDED2 cell is the same as the payload of a + CREATED2 cell. + + [Support for EXTEND2 was added in Tor 0.2.4.8-alpha.] + + Clients SHOULD use the EXTEND format whenever sending a TAP + handshake, and MUST use it whenever the EXTEND cell will be handled + by a node running a version of Tor too old to support EXTEND2. In + other cases, clients SHOULD use EXTEND2. + + When encoding a non-TAP handshake in an EXTEND cell, clients SHOULD + use the format with 'client handshake type tag'. + +5.1.3. The "TAP" handshake + + This handshake uses Diffie-Hellman in Z_p and RSA to compute a set of + shared keys which the client knows are shared only with a particular + server, and the server knows are shared with whomever sent the + original handshake (or with nobody at all). It's not very fast and + 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_S_HANDSHAKE_LEN as DH_LEN+HASH_LEN. + + The payload for a CREATE cell is an 'onion skin', which consists of + the first step of the DH handshake data (also known as g^x). This + value is hybrid-encrypted (see 0.3) to the server's onion key, giving + a client handshake of: + + PK-encrypted: + Padding [PK_PAD_LEN bytes] + Symmetric key [KEY_LEN bytes] + First part of g^x [PK_ENC_LEN-PK_PAD_LEN-KEY_LEN bytes] + Symmetrically encrypted: + Second part of g^x [DH_LEN-(PK_ENC_LEN-PK_PAD_LEN-KEY_LEN) + bytes] + + The payload for a CREATED cell, or the relay payload for an + EXTENDED cell, contains: + DH data (g^y) [DH_LEN bytes] + Derivative key data (KH) [HASH_LEN bytes] <see 5.2 below> + + Once the handshake between the OP and an OR is completed, both can + now calculate g^xy with ordinary DH. Before computing g^xy, both parties + MUST verify that the received g^x or g^y value is not degenerate; + that is, it must be strictly greater than 1 and strictly less than p-1 + where p is the DH modulus. Implementations MUST NOT complete a handshake + with degenerate keys. Implementations MUST NOT discard other "weak" + g^x values. + + (Discarding degenerate keys is critical for security; if bad keys + are not discarded, an attacker can substitute the OR's CREATED + cell's g^y with 0 or 1, thus creating a known g^xy and impersonating + the OR. Discarding other keys may allow attacks to learn bits of + the private key.) + + Once both parties have g^xy, they derive their shared circuit keys + and 'derivative key data' value via the KDF-TOR function in 5.2.1. + +5.1.4. The "ntor" handshake + + This handshake uses a set of DH handshakes to compute a set of + shared keys which the client knows are shared only with a particular + server, and the server knows are shared with whomever sent the + original handshake (or with nobody at all). Here we use the + "curve25519" group and representation as specified in "Curve25519: + new Diffie-Hellman speed records" by D. J. Bernstein. + + [The ntor handshake was added in Tor 0.2.4.8-alpha.] + + In this section, define: + H(x,t) as HMAC_SHA256 with message x and key t. + H_LENGTH = 32. + ID_LENGTH = 20. + G_LENGTH = 32 + PROTOID = "ntor-curve25519-sha256-1" + t_mac = PROTOID | ":mac" + t_key = PROTOID | ":key_extract" + t_verify = PROTOID | ":verify" + MULT(a,b) = the multiplication of the curve25519 point 'a' by the + scalar 'b'. + G = The preferred base point for curve25519 ([9]) + KEYGEN() = The curve25519 key generation algorithm, returning + a private/public keypair. + m_expand = PROTOID | ":key_expand" + + To perform the handshake, the client needs to know an identity key + digest for the server, and an ntor onion key (a curve25519 public + key) for that server. Call the ntor onion key "B". The client + generates a temporary keypair: + x,X = KEYGEN() + and generates a client-side handshake with contents: + NODEID Server identity digest [ID_LENGTH bytes] + KEYID KEYID(B) [H_LENGTH bytes] + CLIENT_PK X [G_LENGTH bytes] + + The server generates a keypair of y,Y = KEYGEN(), and uses its ntor + private key 'b' to compute: + + secret_input = EXP(X,y) | EXP(X,b) | ID | B | X | Y | PROTOID + KEY_SEED = H(secret_input, t_key) + verify = H(secret_input, t_verify) + auth_input = verify | ID | B | Y | X | PROTOID | "Server" + + The server's handshake reply is: + SERVER_PK 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 + + secret_input = EXP(Y,x) | EXP(B,x) | ID | B | X | Y | PROTOID + KEY_SEED = H(secret_input, t_key) + verify = H(secret_input, t_verify) + auth_input = verify | ID | B | Y | X | PROTOID | "Server" + + The client verifies that AUTH == H(auth_input, t_mac). + + Both parties check that none of the EXP() operations produced the + point at infinity. [NOTE: This is an adequate replacement for + checking Y for group membership, if the group is curve25519.] + + Both parties now have a shared value for KEY_SEED. They expand this + into the keys needed for the Tor relay protocol, using the KDF + described in 5.2.2 and the tag m_expand. + +5.1.5. CREATE_FAST/CREATED_FAST cells When initializing the first hop of a circuit, the OP has already established the OR's identity and negotiated a secret key using TLS. @@ -717,10 +910,13 @@ see tor-design.pdf. A CREATED_FAST cell contains: Key material (Y) [HASH_LEN bytes] - Derivative key data [HASH_LEN bytes] (See 5.2 below) + Derivative key data [HASH_LEN bytes] (See 5.2.1 below) The values of X and Y must be generated randomly. + Once both parties have X and Y, they derive their shared circuit keys + and 'derivative key data' value via the KDF-TOR function in 5.2.1. + If an OR sees a circuit created with CREATE_FAST, the OR is sure to be the first hop of a circuit. ORs SHOULD reject attempts to create streams with RELAY_BEGIN exiting the circuit at the first hop: letting Tor be used as a @@ -728,21 +924,13 @@ see tor-design.pdf. 5.2. Setting circuit keys - Once the handshake between the OP and an OR is completed, both can - now calculate g^xy with ordinary DH. Before computing g^xy, both parties - MUST verify that the received g^x or g^y value is not degenerate; - that is, it must be strictly greater than 1 and strictly less than p-1 - where p is the DH modulus. Implementations MUST NOT complete a handshake - with degenerate keys. Implementations MUST NOT discard other "weak" - g^x values. +5.2.1. KDF-TOR - (Discarding degenerate keys is critical for security; if bad keys - are not discarded, an attacker can substitute the OR's CREATED - cell's g^y with 0 or 1, thus creating a known g^xy and impersonating - the OR. Discarding other keys may allow attacks to learn bits of - the private key.) + This key derivation function is used by the TAP and CREATE_FAST + handshakes, and in the current hidden service protocol. It shouldn't + be used for new functionality. - If CREATE or EXTEND is used to extend a circuit, both parties + If the TAP handshake is used to extend a circuit, both parties base their key material on K0=g^xy, represented as a big-endian unsigned integer. @@ -765,6 +953,28 @@ see tor-design.pdf. is used to encrypt the stream of data going from the OP to the OR, and Kb is used to encrypt the stream of data going from the OR to the OP. +5.2.2. KDF-RFC5869 + + For newer KDF needs, Tor uses the key derivation function HKDF from + RFC5869, instantiated with SHA256. (This is due to a construction + from Krawczyk.) The generated key material is: + + K = K_1 | K_2 | K_3 | ... + + Where H(x,t) is HMAC_SHA256 with value x and key t + and K_1 = H(m_expand | INT8(1) , KEY_SEED ) + and K_(i+1) = H(K_i | m_expand | INT8(i) , KEY_SEED ) + and m_expand is an arbitrarily chosen value, + and INT8(i) is a octet with the value "i". + + In RFC5869's vocabulary, this is HKDF-SHA256 with info == m_expand, + salt == t_key, and IKM == secret_input. + + When used in the ntor handshake, the first HASH_LEN bytes form the + forward digest Df; the next HASH_LEN form the backward digest Db; the + next KEY_LEN form Kf, and the final KEY_LEN form Kb. Excess bytes + from K are discarded. + 5.3. Creating circuits When creating a circuit through the network, the circuit creator @@ -808,7 +1018,7 @@ see tor-design.pdf. all zeroes, or asks to extend back to the relay that sent the extend cell, the circuit will fail and be torn down. The initiating onion router chooses some circID not yet used on the connection between the - two onion routers. (But see section 5.1. above, concerning choosing + two onion routers. (But see section 5.1.1 above, concerning choosing circIDs based on lexicographic order of nicknames.) When an onion router receives a CREATE cell, if it already has a @@ -989,6 +1199,8 @@ see tor-design.pdf. 11 -- RELAY_RESOLVE [forward] 12 -- RELAY_RESOLVED [backward] 13 -- RELAY_BEGIN_DIR [forward] + 14 -- RELAY_EXTEND2 [forward] [control] + 15 -- RELAY_EXTENDED2 [backward] [control] 32..40 -- Used for hidden services; see rend-spec.txt.

1 0

[torspec/master] Document IPv6-exit features in the specs
by nickm＠torproject.org 14 Mar '13

14 Mar '13

commit 8d7b559728a5361b9379d75a8e0741bc6ffd5881 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Mar 13 13:20:51 2013 -0400 Document IPv6-exit features in the specs Closes proposals 117 and 208 --- dir-spec.txt | 24 ++++++++++++++++++++++-- proposals/117-ipv6-exits.txt | 2 +- proposals/208-ipv6-exits-redux.txt | 2 +- tor-spec.txt | 19 ++++++++++++++++--- 4 files changed, 40 insertions(+), 7 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index c5ca5c1..dd4a9c9 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -476,6 +476,14 @@ the address will be accepted. For clarity, the last such entry SHOULD be accept *:* or reject *:*. + "ipv6-policy" SP ("accept" / "reject") SP PortList NL + + [At most once.] + + An exit-policy summary as specified in 3.3 and 3.5.2, summarizing + the router's rules for connecting to IPv6 addresses. A missing + "ipv6-policy" line is equivalent to "ipv6-policy reject 1-65535". + "router-signature" NL Signature NL [At end, exactly once] @@ -1114,7 +1122,7 @@ The "ntor-onion-key" element as specified in 2.1. - (Only included when the vote or consensus is generated with + (Only included when generating microdescriptors for consensus-method 16 or later.) "a" SP address ":" portlist NL @@ -1141,6 +1149,17 @@ BEGIN request, and might get end-reason-exit-policy if they guessed wrong, in which case they'll have to try elsewhere.] + "p6" SP ("accept" / "reject") SP PortList NL + + [At most once] + + The IPv6 exit policy summary as specified in 3.3 and 3.5.2. A + missing "p6" line is equivalent to "p6 reject 1-65535". + + (Only included when generating microdescriptors for + consensus-method 15 or later.) + + (Note that with microdescriptors, clients do not learn the identity of their routers: they only learn a hash of the identity key. This is all they need to confirm the actual identity key when doing a TLS handshake, @@ -1855,7 +1874,8 @@ consensuses may include "a" lines listing additional OR ports. - * XXXXX 15 + * If consensus method 15 or later is used, microdescriptors + include "p6" lines including IPv6 exit policies. * If consensus method 16 or later is used, ntor-onion-key are included in microdescriptors diff --git a/proposals/117-ipv6-exits.txt b/proposals/117-ipv6-exits.txt index 9c51cf2..f343ff7 100644 --- a/proposals/117-ipv6-exits.txt +++ b/proposals/117-ipv6-exits.txt @@ -2,7 +2,7 @@ Filename: 117-ipv6-exits.txt Title: IPv6 exits Author: coderman Created: 10-Jul-2007 -Status: Finished +Status: Closed Target: 0.2.4.x Implemented-In: 0.2.4.7-alpha diff --git a/proposals/208-ipv6-exits-redux.txt b/proposals/208-ipv6-exits-redux.txt index e25a901..32fb09c 100644 --- a/proposals/208-ipv6-exits-redux.txt +++ b/proposals/208-ipv6-exits-redux.txt @@ -2,7 +2,7 @@ Filename: 208-ipv6-exits-redux.txt Title: IPv6 Exits Redux Author: Nick Mathewson Created: 10-Oct-2012 -Status: Finished +Status: Closed Target: 0.2.4.x Implemented-In: 0.2.4.7-alpha diff --git a/tor-spec.txt b/tor-spec.txt index 0c333e7..6831744 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -1252,14 +1252,27 @@ see tor-design.pdf. and constructs a RELAY_BEGIN cell with a payload encoding the address and port of the destination host. The payload format is: - ADDRESS | ':' | PORT | [00] + ADDRPORT [nul-terminated string] + FLAGS [4 bytes] + + ADDRPORT is made of ADDRESS | ':' | PORT | [00] where ADDRESS can be a DNS hostname, or an IPv4 address in dotted-quad format, or an IPv6 address surrounded by square brackets; and where PORT is a decimal integer between 1 and 65535, inclusive. - [What is the [00] for? -NM] - [It's so the payload is easy to parse out with string funcs -RD] + The FLAGS value has one or more of the following bits set, where + "bit 1" is the LSB of the 32-bit value, and "bit 32" is the MSB. + bit meaning + 1 -- IPv6 okay. We support learning about IPv6 addresses and + connecting to IPv6 addresses. + 2 -- IPv4 not okay. We don't want to learn about IPv4 addresses + or connect to them. + 3 -- IPv6 preferred. If there are both IPv4 and IPv6 addresses, + we want to connect to the IPv6 one. (By default, we connect + to the IPv4 address.) + 4..32 -- Reserved. Current clients MUST NOT set these. Servers + MUST ignore them. Upon receiving this cell, the exit node resolves the address as necessary, and opens a new TCP connection to the target port. If the

1 0

[torspec/master] Specify consensus method 17 and the maxunmeasuredbw field.
by nickm＠torproject.org 14 Mar '13

14 Mar '13

commit c3860e315803bf974ce4b9807cacfecd79a46ea9 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Mar 13 13:32:27 2013 -0400 Specify consensus method 17 and the maxunmeasuredbw field. --- dir-spec.txt | 19 ++++++++++++++++--- 1 files changed, 16 insertions(+), 3 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index dd4a9c9..bdb25de 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -1388,6 +1388,11 @@ received a RELAY_CONNECTED cell. Min: 0, Max: 1 + "maxunmeasuredbw" -- Used by authorities during voting with + method 17 or later. The maximum value to give for any Bandwidth= + entry for a router that isn't based on at least three + measurements. + The authority section of a vote contains the following items, followed in turn by the authority's current key certificate: @@ -1523,7 +1528,7 @@ descriptors if they would cause "v" lines to be over 128 characters long. - "w" SP "Bandwidth=" INT [SP "Measured=" INT] NL + "w" SP "Bandwidth=" INT [SP "Measured=" INT] [SP "Unmeasured=1"] NL [At most once.] @@ -1534,7 +1539,11 @@ Additionally, the Measured= keyword is present in votes by participating bandwidth measurement authorities to indicate a measured bandwidth currently produced by measuring stream - capacities. + capacities. It does not occur in consensuses. + + The "Unmeasured=1" value is included in consensuses generated + with method 17 or later when the 'Bandwidth=' value is not + based on a threshold of 3 or more measurements. Other weighting keywords may be added later. Clients MUST ignore keywords they do not recognize. @@ -1880,7 +1889,11 @@ * If consensus method 16 or later is used, ntor-onion-key are included in microdescriptors - * XXXXX 17 + * If consensus method 17 or later is used, authorities impose a + maximum on the Bandwidth= values that they'll put on a 'w' + line for any router that doesn't have at least 3 measured + bandwidth values in votes. They also add an "Unmeasured=1" + flag to such 'w' lines. The signatures at the end of a consensus document are sorted in ascending order by identity digest.

1 0

[torspec/master] Merge 4-byte circids (prop 214) into the spec.
by nickm＠torproject.org 14 Mar '13

14 Mar '13

commit 55d5de76644522dc9c2bf8f6429006d21d3b2c5f Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Mar 13 14:00:24 2013 -0400 Merge 4-byte circids (prop 214) into the spec. --- proposals/214-longer-circids.txt | 3 +- tor-spec.txt | 62 +++++++++++++++++++++++-------------- 2 files changed, 40 insertions(+), 25 deletions(-) diff --git a/proposals/214-longer-circids.txt b/proposals/214-longer-circids.txt index 3277a9c..9494984 100644 --- a/proposals/214-longer-circids.txt +++ b/proposals/214-longer-circids.txt @@ -2,7 +2,8 @@ Filename: 214-longer-circids.txt Title: Allow 4-byte circuit IDs in a new link protocol Author: Nick Mathewson Created: 6 Nov 2012 -Status: Finished +Status: Closed +Implemented-In: 0.2.4.11-alpha 0. Overview diff --git a/tor-spec.txt b/tor-spec.txt index 6831744..9aea142 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -57,7 +57,10 @@ see tor-design.pdf. PAYLOAD_LEN -- The longest allowable cell payload, in bytes. (509) - CELL_LEN -- The length of a Tor cell, in bytes. + CELL_LEN(v) -- The length of a Tor cell, in bytes, for link protocol + version v. + CELL_LEN(v) = 512 if v is less than 4; + = 514 otherwise. 0.3. Ciphers @@ -117,10 +120,6 @@ see tor-design.pdf. see Goldberg's PET2006 paper for details. We will add a MAC to this scheme one day. -RD] -0.4. Other parameter values - - CELL_LEN=512 - 1. System overview Tor is a distributed overlay network designed to anonymize @@ -274,11 +273,11 @@ see tor-design.pdf. Once a TLS connection is established, the two sides send cells (specified below) to one another. Cells are sent serially. Standard - cells are CELL_LEN bytes long, but variable-length cells also exist; see - Section 3. Cells may be sent embedded in TLS - records of any size or divided across TLS records, but the framing - of TLS records MUST NOT leak information about the type or contents - of the cells. + cells are CELL_LEN(link_proto) bytes long, but variable-length cells + also exist; see Section 3. Cells may be sent embedded in TLS records + of any size or divided across TLS records, but the framing of TLS + records MUST NOT leak information about the type or contents of the + cells. TLS connections are not permanent. Either side MAY close a connection if there are no circuits running over it and an amount of time @@ -357,14 +356,14 @@ see tor-design.pdf. On a version 1 connection, each cell contains the following fields: - CircID [2 bytes] + CircID [CIRCID_LEN bytes] Command [1 byte] Payload (padded with 0 bytes) [PAYLOAD_LEN bytes] - On a version 2 or 3 connection, all cells are as in version 1 connections, - except for variable-length cells, whose format is: + On a version 2 or higher connection, all cells are as in version 1 + connections, except for variable-length cells, whose format is: - CircID [2 octets] + CircID [CIRCID_LEN octets] Command [1 octet] Length [2 octets; big-endian integer] Payload [Length bytes] @@ -374,6 +373,10 @@ see tor-design.pdf. higher connection, variable-length cells are indicated by a command byte equal to 7 ("VERSIONS"), or greater than or equal to 128. + CIRCID_LEN is 2 for link protocol versions 1, 2, and 3. CIRCID_LEN + is 4 for link protocol version 4 or higher. The VERSIONS cell itself + always has CIRCID_LEN == 2 for backward compatibility. + The CircID field determines which circuit, if any, the cell is associated with. @@ -493,6 +496,13 @@ see tor-design.pdf. used, implementations MUST NOT list any version before 3, and SHOULD list at least version 3. + Link protocols differences are: + 1 -- The "certs up front" handshake. + 2 -- Uses the renegotiation-based handshake. Introduces + varible-length cells. + + + 4.2. CERTS cells The CERTS cell describes the keys that a Tor instance is claiming @@ -710,20 +720,24 @@ see tor-design.pdf. 5.1.1. Choosing circuit IDs in create cells - The CircID for a CREATE cell is an arbitrarily chosen nonzero 2-byte - integer, selected by the node (OP or OR) that sends the CREATE cell. + The CircID for a CREATE cell is an arbitrarily chosen nonzero integer, + selected by the node (OP or OR) that sends the CREATE cell. In link + protocol 3 or lower, CircIDs are 2 bytes long; in protocol 4 or + higher, CircIDs are 4 bytes long. + To prevent CircID collisions, when one node sends a CREATE cell to another, it chooses from only one half of the possible values based - on the ORs' public identity keys: if the sending node has a lower - key, it chooses a CircID with an MSB of 0; otherwise, it chooses a - CircID with an MSB of 1. - [XXXX fix this when documenting link protocol 4.] + on the ORs' public identity keys. In link protocol version 3 or + lower, if the sending node has a lower key, it chooses a CircID with + an MSB of 0; otherwise, it chooses a CircID with an MSB of 1. (Public + keys are compared numerically by modulus.) + + In link protocol version 4 or higher, whichever node initiated the + connection sets its MSB to 0, and whichever node didn't initiate the + connection sets its MSB to 1. (An OP with no public key MAY choose any CircID it wishes, since an OP never needs to process a CREATE cell.) - [XXXX fix this when documenting link protocol 4.] - - Public keys are compared numerically by modulus. 5.1.2. EXTEND and EXTENDED cells @@ -1183,7 +1197,7 @@ see tor-design.pdf. StreamID [2 bytes] Digest [4 bytes] Length [2 bytes] - Data [CELL_LEN-14 bytes] + Data [PAYLOAD_LEN-11 bytes] The relay commands are: 1 -- RELAY_BEGIN [forward]

1 0

[torspec/master] Make it more explicit that everything in tor-spec is big-endian
by nickm＠torproject.org 14 Mar '13

14 Mar '13

commit 81702d1d830a81b4920cd04851d43e3e5eb1ba27 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Mar 13 23:30:23 2013 -0400 Make it more explicit that everything in tor-spec is big-endian Clarify what we mean when we talk about the MSB of a big-endian value. --- tor-spec.txt | 15 +++++++++++++-- 1 files changed, 13 insertions(+), 2 deletions(-) diff --git a/tor-spec.txt b/tor-spec.txt index 9aea142..b9834bc 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -33,10 +33,17 @@ see tor-design.pdf. [A0 B1 C2] -- a three-byte sequence, containing the bytes with hexadecimal values A0, B1, and C2, in that order. - All numeric values are encoded in network (big-endian) order. - H(m) -- a cryptographic hash of m. + We use "byte" and "octet" interchangeably. Possibly we shouldn't. + +0.1.1. Encoding integers + + Unless we explicitly say otherwise below, all numeric values in the + Tor protocol are encoded in network (big-endian) order. So a "32-bit + integer" means a big-endian 32-bit integer; a "2-byte" integer means + a big-endian 16-bit integer, and so forth. + 0.2. Security parameters Tor uses a stream cipher, a public-key cipher, the Diffie-Hellman @@ -1277,6 +1284,10 @@ see tor-design.pdf. The FLAGS value has one or more of the following bits set, where "bit 1" is the LSB of the 32-bit value, and "bit 32" is the MSB. + (Remember that all values in Tor are big-endian (see 0.1.1 above), so + the MSB of a 4-byte value is the MSB of the first byte, and the LSB + of a 4-byte value is the LSB of its last byte.) + bit meaning 1 -- IPv6 okay. We support learning about IPv6 addresses and connecting to IPv6 addresses.

1 0

[torspec/master] Merge branch 'more-specs-squashed'
by nickm＠torproject.org 14 Mar '13

14 Mar '13

commit f2cf4ab55825b1e6584f85ed54dff58e9c11c1b3 Merge: 6a3234a 81702d1 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Mar 14 12:42:29 2013 -0400 Merge branch 'more-specs-squashed' dir-spec.txt | 65 ++++- proposals/117-ipv6-exits.txt | 2 +- proposals/200-new-create-and-extend-cells.txt | 3 +- proposals/208-ipv6-exits-redux.txt | 2 +- proposals/214-longer-circids.txt | 3 +- proposals/216-ntor-handshake.txt | 3 +- tor-spec.txt | 398 ++++++++++++++++++++----- 7 files changed, 394 insertions(+), 82 deletions(-)

1 0

[torspec/master] Update index
by nickm＠torproject.org 14 Mar '13

14 Mar '13

commit 17345bb53a7fc3f8294c4243720b2f0ee129b64e Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Mar 14 12:43:06 2013 -0400 Update index --- proposals/000-index.txt | 20 ++++++++++---------- 1 files changed, 10 insertions(+), 10 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 3a04148..112ea4b 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -37,7 +37,7 @@ Proposals by number: 114 Distributed Storage for Tor Hidden Service Descriptors [CLOSED] 115 Two Hop Paths [DEAD] 116 Two hop paths from entry guards [DEAD] -117 IPv6 exits [FINISHED] +117 IPv6 exits [CLOSED] 118 Advertising multiple ORPorts at once [SUPERSEDED] 119 New PROTOCOLINFO command for controllers [CLOSED] 120 Shutdown descriptors when Tor servers stop [DEAD] @@ -120,7 +120,7 @@ Proposals by number: 197 Message-based Inter-Controller IPC Channel [OPEN] 198 Restore semantics of TLS ClientHello [FINISHED] 199 Integration of BridgeFinder and BridgeFinderHelper [OPEN] -200 Adding new, extensible CREATE, EXTEND, and related cells [FINISHED] +200 Adding new, extensible CREATE, EXTEND, and related cells [CLOSED] 201 Make bridges report statistics on daily v3 network status requests [OPEN] 202 Two improved relay encryption protocols for Tor cells [OPEN] 203 Avoiding censorship by impersonating an HTTPS server [DRAFT] @@ -128,15 +128,15 @@ Proposals by number: 205 Remove global client-side DNS caching [CLOSED] 206 Preconfigured directory sources for bootstrapping [CLOSED] 207 Directory guards [CLOSED] -208 IPv6 Exits Redux [FINISHED] +208 IPv6 Exits Redux [CLOSED] 209 Tuning the Parameters for the Path Bias Defense [OPEN] 210 Faster Headless Consensus Bootstrapping [OPEN] 211 Internal Mapaddress for Tor Configuration Testing [OPEN] 212 Increase Acceptable Consensus Age [OPEN] 213 Remove stream-level sendmes from the design [OPEN] -214 Allow 4-byte circuit IDs in a new link protocol [OPEN] +214 Allow 4-byte circuit IDs in a new link protocol [CLOSED] 215 Let the minimum consensus method change with time [OPEN] -216 Improved circuit-creation key exchange [FINISHED] +216 Improved circuit-creation key exchange [CLOSED] 217 Tor Extended ORPort Authentication [OPEN] 218 Controller events to better understand connection/circuit usage [OPEN] @@ -183,7 +183,6 @@ Proposals by status: 211 Internal Mapaddress for Tor Configuration Testing [for 0.2.4.x+] 212 Increase Acceptable Consensus Age [for 0.2.4.x+] 213 Remove stream-level sendmes from the design - 214 Allow 4-byte circuit IDs in a new link protocol 215 Let the minimum consensus method change with time 217 Tor Extended ORPort Authentication [for 0.2.5.x] 218 Controller events to better understand connection/circuit usage [for 0.2.5.x] @@ -200,7 +199,6 @@ Proposals by status: 098 Proposals that should be written 099 Miscellaneous proposals FINISHED: - 117 IPv6 exits [for 0.2.4.x] [in 0.2.4.7-alpha] 121 Hidden Service Authentication [in 0.2.1.x] 151 Improving Tor Path Selection 155 Four Improvements of Hidden Service Performance [in 0.2.1.x] @@ -210,10 +208,7 @@ Proposals by status: 162 Publish the consensus in multiple flavors [in 0.2.3.1-alpha] 180 Pluggable transports for circumvention [in 0.2.3.x] 198 Restore semantics of TLS ClientHello [for 0.2.4.x] - 200 Adding new, extensible CREATE, EXTEND, and related cells 204 Subdomain support for Hidden Service addresses - 208 IPv6 Exits Redux [for 0.2.4.x] [in 0.2.4.7-alpha] - 216 Improved circuit-creation key exchange CLOSED: 101 Voting on the Tor Directory System [in 0.2.0.x] 102 Dropping "opt" from the directory format [in 0.2.0.x] @@ -227,6 +222,7 @@ Proposals by status: 110 Avoiding infinite length circuits [for 0.2.3.x] [in 0.2.1.3-alpha, 0.2.3.11-alpha] 111 Prioritizing local traffic over relayed traffic [in 0.2.0.x] 114 Distributed Storage for Tor Hidden Service Descriptors [in 0.2.0.x] + 117 IPv6 exits [for 0.2.4.x] [in 0.2.4.7-alpha] 119 New PROTOCOLINFO command for controllers [in 0.2.0.x] 122 Network status entries need a new Unnamed flag [in 0.2.0.x] 123 Naming authorities automatically create bindings [in 0.2.0.x] @@ -254,9 +250,13 @@ Proposals by status: 184 Miscellaneous changes for a v3 Tor link protocol [for 0.2.3.x] 187 Reserve a cell type to allow client authorization [for 0.2.3.x] 193 Safe cookie authentication for Tor controllers + 200 Adding new, extensible CREATE, EXTEND, and related cells [in 0.2.4.8-alpha] 205 Remove global client-side DNS caching [in 0.2.4.7-alpha.] 206 Preconfigured directory sources for bootstrapping [in 0.2.4.7-alpha] 207 Directory guards [for 0.2.4.x] + 208 IPv6 Exits Redux [for 0.2.4.x] [in 0.2.4.7-alpha] + 214 Allow 4-byte circuit IDs in a new link protocol [in 0.2.4.11-alpha] + 216 Improved circuit-creation key exchange [in 0.2.4.8-alpha] SUPERSEDED: 112 Bring Back Pathlen Coin Weight 113 Simplifying directory authority administration

1 0