December 2017 - tor-commits - lists.torproject.org

[torspec/master] mark prop280 as superseded
by nickm＠torproject.org 01 Dec '17

01 Dec '17

commit 0596c2cbb2776f28dab885d115459ac4a09f0186 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Dec 1 15:25:35 2017 -0500 mark prop280 as superseded --- proposals/000-index.txt | 4 ++-- proposals/280-privcount-in-tor.txt | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 4b055f0..f194667 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -200,7 +200,7 @@ Proposals by number: 277 Detect multiple relay instances running with same ID [OPEN] 278 Directory Compression Scheme Negotiation [FINISHED] 279 A Name System API for Tor Onion Services [DRAFT] -280 Privacy-Preserving Statistics with Privcount in Tor [DRAFT] +280 Privacy-Preserving Statistics with Privcount in Tor [SUPERSEDED] 281 Downloading microdescriptors in bulk [DRAFT] 282 Remove "Named" and "Unnamed" handling from consensus voting [OPEN] 283 Move IPv6 ORPorts from microdescriptors to the microdesc consensus [OPEN] @@ -232,7 +232,6 @@ Proposals by status: 270 RebelAlliance: A Post-Quantum Secure Hybrid Handshake Based on NewHope 273 Exit relay pinning for web services [for n/a] 279 A Name System API for Tor Onion Services - 280 Privacy-Preserving Statistics with Privcount in Tor 281 Downloading microdescriptors in bulk 288 Privacy-Preserving Statistics with Privcount in Tor (Shamir version) NEEDS-REVISION: @@ -390,6 +389,7 @@ Proposals by status: 225 Strawman proposal: commit-and-reveal shared rng 252 Single Onion Services 266 Removing current obsolete clients from the Tor network + 280 Privacy-Preserving Statistics with Privcount in Tor DEAD: 100 Tor Unreliable Datagram Extension Proposal 115 Two Hop Paths diff --git a/proposals/280-privcount-in-tor.txt b/proposals/280-privcount-in-tor.txt index 9b1a8b5..fd5a011 100644 --- a/proposals/280-privcount-in-tor.txt +++ b/proposals/280-privcount-in-tor.txt @@ -2,7 +2,8 @@ Filename: 280-privcount-in-tor.txt Title: Privacy-Preserving Statistics with Privcount in Tor Author: Nick Mathewson, Tim Wilson-Brown Created: 02-Aug-2017 -Status: Draft +Status: Superseded +Superseded-By: 288 0. Acknowledgments

1 0

[torspec/master] Add privcount-with-shamir proposal
by nickm＠torproject.org 01 Dec '17

01 Dec '17

commit 8f56a246f8c2501e1c52594f804292ad6b7cca06 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Dec 1 15:25:10 2017 -0500 Add privcount-with-shamir proposal --- proposals/000-index.txt | 2 + proposals/288-privcount-with-shamir.txt | 564 ++++++++++++++++++++++++++++++++ 2 files changed, 566 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index dd9abdc..4b055f0 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -208,6 +208,7 @@ Proposals by number: 285 Directory documents should be standardized as UTF-8 [OPEN] 286 Controller APIs for hibernation access on mobile [OPEN] 287 Reduce circuit lifetime without overloading the network [OPEN] +288 Privacy-Preserving Statistics with Privcount in Tor (Shamir version) [DRAFT] Proposals by status: @@ -233,6 +234,7 @@ Proposals by status: 279 A Name System API for Tor Onion Services 280 Privacy-Preserving Statistics with Privcount in Tor 281 Downloading microdescriptors in bulk + 288 Privacy-Preserving Statistics with Privcount in Tor (Shamir version) NEEDS-REVISION: 190 Bridge Client Authorization Based on a Shared Secret NEEDS-RESEARCH: diff --git a/proposals/288-privcount-with-shamir.txt b/proposals/288-privcount-with-shamir.txt new file mode 100644 index 0000000..4489048 --- /dev/null +++ b/proposals/288-privcount-with-shamir.txt @@ -0,0 +1,564 @@ +Filename: 288-privcount-with-shamir.txt +Title: Privacy-Preserving Statistics with Privcount in Tor (Shamir version) +Author: Nick Mathewson, Tim Wilson-Brown, Aaron Johnson +Created: 1-Dec-2017 +Supercedes: 280 +Status: Draft + +0. Acknowledgments + + Tariq Elahi, George Danezis, and Ian Goldberg designed and implemented + the PrivEx blinding scheme. Rob Jansen and Aaron Johnson extended + PrivEx's differential privacy guarantees to multiple counters in + PrivCount: + + https://github.com/privcount/privcount/blob/master/README.markdown#research… + + Rob Jansen and Tim Wilson-Brown wrote the majority of the experimental + PrivCount code, based on the PrivEx secret-sharing variant. This + implementation includes contributions from the PrivEx authors, and + others: + + https://github.com/privcount/privcount/blob/master/CONTRIBUTORS.markdown + + This research was supported in part by NSF grants CNS-1111539, + CNS-1314637, CNS-1526306, CNS-1619454, and CNS-1640548. + + The use of a Shamir secret-sharing-based approach is due to a + suggestion by Aaron Johnson (iirc); Carolin Zöbelein did some helpful + analysis here. + + Aaron Johnson and Tim Wilson-Brown made improvements to the draft proposal. + +1. Introduction and scope + + PrivCount is a privacy-preserving way to collect aggregate statistics + about the Tor network without exposing the statistics from any single + Tor relay. + + This document describes the behavior of the in-Tor portion of the + PrivCount system. It DOES NOT describe the counter configurations, + or any other parts of the system. (These will be covered in separate + proposals.) + +2. PrivCount overview + + Here follows an oversimplified summary of PrivCount, with enough + information to explain the Tor side of things. The actual operation + of the non-Tor components is trickier than described below. + + In PrivCount, a Data Collector (DC, in this case a Tor relay) shares + numeric data with N different Tally Reporters (TRs). (A Tally Reporter + performs the summing and unblinding roles of the Tally Server and Share + Keeper from experimental PrivCount.) + + All N Tally Reporters together can reconstruct the original data, but + no (N-1)-sized subset of the Tally Reporters can learn anything about + the data. + + (In reality, the Tally Reporters don't reconstruct the original data + at all! Instead, they will reconstruct a _sum_ of the original data + across all participating relays.) + + In brief, the system works as follow: + + To share data, for each counter value V to be shared, the Data Collector + first adds Gaussian noise to V in order to produce V', uses (K,N) Shamir + secret-sharing to generate N shares of V' (K<=N, K being the + reconstruction threshold), encrypts each share to a different Tally + Reporter, and sends each encrypted share to the Tally Reporter it + is encrypted for. + + The Tally Reporters then agree on the set S of Data Collectors that sent + data to all of them, and each Tally Reporter forms a share of the aggregate + value by decrypting the shares it received from the Data Collectors in S + and adding them together. The Tally Reporters then, collectively, perform + secret reconstruction, thereby learning the sum of all the different + values V'. + + The use of Shamir secret sharing lets us survive up to N-K crashing TRs. + Waiting until the end to agree on a set S of surviving relays lets us + survive an arbitrary number of crashing DCs. In order to prevent bogus + data from corrupting the tally, the Tally Reporters can perform the + aggregation step multiple times, each time proceeding with a different + subset of S and taking the median of the resulting values. + + Relay subsets should be chosen at random to avoid relays manipulating their + subset membership(s). If an shared random value is required, all relays must + submit their results, and then the next revealed shared random value can + be used to select relay subsets. (Tor's shared random value can be + calculated as soon as all commits have been revealed. So all relay results + must be received *before* any votes are cast in the reveal phase for that + shared random value.) + + Below we describe the algorithm in more detail, and describe the data + format to use. + +3. The algorithm + + All values below are B-bit integers modulo some prime P; we suggest + B=62 and P = 2**62 - 2**30 - 1 (hex 0x3fffffffbfffffff). The size of + this field is an upper limit on the largest sum we can calculate; it + is not a security parameter. + + There are N Tally Reporters: every participating relay must agree on + which N exist, and on their current public keys. We suggest listing + them in the consensus networkstatus document. All parties must also + agree on some ordering the Tally Reporters. Similarly, all parties + must also agree on some value K<=N. + + There are a number of well-known "counters", identified known by ASCII + identifiers. Each counter is a value that the participating relays + will know how to count. Let C be the number of counters. + +3.1. Data Collector (DC) side + + At the start of each period, every Data Collector ("client" below) + initializes their state as follows + + 1. For every Tally Reporter with index i, the client constructs a + random 32-byte random value SEED_i. The client then generates + a pseudorandom bitstream of C*B bits using the SHAKE-256 + XOF with SEED_i as its input, and divides this stream into + C values, with the c'th value denoted by MASK(i, c). + + [Because P is very close to a power of 2, nearly all seeds will + produce MASK values in range 0...(P-1). If any does not, the + client picks a new seed.] + + 2. The client encrypts SEED_i using the public key of Tally + Reporter i, and remembers this encrypted value. It discards + SEED_i. + + 3. For every counter c, the client generates a noise value Z_c + from an appropriate Gaussian distribution. If the noise value is + negative, the client adds P to bring Z_c into the range 0...(P-1). + (The noise MUST be sampled using the procedure in Appendix C.) + + The client then uses Shamir secret sharing to generate + N shares (x,y) of Z_c, 1 <= x <= N, with the x'th share to be used by + the x'th Tally Reporter. See Appendix A for more on Shamir secret + sharing. See Appendix B for another idea about X coordinates. + + The client picks a random value CTR_c and stores it in the counter, + which serves to locally blind the counter. + + The client then subtracts (MASK(x, c)+CTR_c) from y, giving + "encrypted shares" of (x, y0) where y0 = y-CTR_c. + + The client then discards all MASK values, all CTR values, and all + original shares (x,y), all CTR and the noise value Z_c. For each + counter c, it remembers CTR_c, and N shares of the form (x, y). + + To increment a counter by some value "inc": + + 1. The client adds "inc" to counter value, modulo P. + + (This step is chosen to be optimal, since it will happen more + frequently than any other step in the computation.) + + Aggregate counter values that are close to P/2 MUST be scaled to + avoid overflow. See Appendix D for more information. (We do not think + that any counters on the current Tor network will require scaling.) + + To publish the counter values: + + 1. The client publishes, in the format described below: + + The list of counters it knows about + The list of TRs it knows about + For each TR: + For each counter c: + A list of (i, y-CTR_c-MASK(x,c)), which corresponds + to the share for the i'th TR of counter c. + SEED_i as encrypted earlier to the i'th TR's public key. + +3.2. Tally Reporter (TR) side + + This section is less completely specified than the Data Collector's + behavior: I expect that the TRs will be easier to update as we proceed. + + (Each TR has a long-term identity key (ed25519). It also has a + sequence of short-term curve25519 keys, each associated with a single + round of data collection.) + + 1. When a group of TRs receives information from the Data Collectors, + they collectively chose a set S of DCs and a set of counters such + that every TR in the group has a valid entry for every counter, + from every DC in the set. + + To be valid, an entry must not only be well-formed, but must also + have the x coordinate in its shares corresponding to the + TR's position in the list of TRs. + + 2. For each Data Collector's report, the i'th TR decrypts its part of + the client's report using its curve25519 key. It uses SEED_i and + SHAKE-256 to regenerate MASK(0) through MASK(C-1). Then for each + share (x, y-CTR_c-MASK(x,c)) (note that x=i), the TR reconstructs the + true share of the value for that DC and counter c by adding + V+MASK(x,c) to the y coordinate to yield the share (x, y_final). + + 3. For every counter in the set, each TR computes the sum of the + y_final values from all clients. + + 4. For every counter in the set, each TR publishes its a share of + the sum as (x, SUM(y_final)). + + 5. If at least K TRs publish correctly, then the sum can be + reconstructed using Lagrange polynomial interpolation. (See + Appendix A). + + 6. If the reconstructed sum is greater than P/2, it is probably a negative + value. The value can be obtained by subtracting P from the sum. + (Negative values are generated when negative noise is added to small + signals.) + + 7. If scaling has been applied, the sum is scaled by the scaling factor. + (See Appendix D.) + +4. The document format + +4.1. The counters document. + + This document format builds on the line-based directory format used + for other tor documents, described in Tor's dir-spec.txt. + + Using this format, we describe a "counters" document that publishes + the shares collected by a given DC, for a single TR. + + The "counters" document has these elements: + + "privctr-dump-format" SP VERSION SP SigningKey + + [At start, exactly once] + + Describes the version of the dump format, and provides an ed25519 + signing key to identify the relay. The signing key is encoded in + base64 with padding stripped. VERSION is "alpha" now, but should + be "1" once this document is finalized. + + "starting-at" SP IsoTime + + [Exactly once] + + The start of the time period when the statistics here were + collected. + + "ending-at" SP IsoTime + + [Exactly once] + + The end of the time period when the statistics here were + collected. + + "share-parameters" SP Number SP Number + + [Exactly once] + + The number of shares needed to reconstruct the client's + measurements (K), and the number of shares produced (N), + respectively. + + "tally-reporter" SP Identifier SP Integer SP Key + + [At least twice] + + The curve25519 public key of each Tally Reporter that the relay + believes in. (If the list does not match the list of + participating Tally Reporters, they won't be able to find the + relay's values correctly.) The identifiers are non-space, + non-nul character sequences. The Key values are encoded in + base64 with padding stripped; they must be unique within each + counters document. The Integer values are the X coordinate of + the shares associated with each Tally Reporter. + + "encrypted-to-key" SP Key + + [Exactly once] + + The curve25519 public key to which the report below is encrypted. + Note that it must match one of the Tally Reporter options above. + + + "report" NL + "----- BEGIN ENCRYPTED MESSAGE-----" NL + Base64Data + "----- END ENCRYPTED MESSAGE-----" NL + + [Exactly once] + + An encrypted document, encoded in base64. The plaintext format is + described in section 4.2. below. The encryption is as specified in + section 5 below, with STRING_CONSTANT set to "privctr-shares-v1". + + "signature" SP Signature + + [At end, exactly once] + + The Ed25519 signature of all the fields in the document, from the + first byte, up to but not including the "signature" keyword here. + The signature is encoded in base64 with padding stripped. + +4.2. The encrypted "shares" document. + + The shares document is sent, encrypted, in the "report" element above. + Its plaintext contents include these fields: + + "encrypted-seed" NL + "----- BEGIN ENCRYPTED MESSAGE-----" NL + Base64Data + "----- END ENCRYPTED MESSAGE-----" NL + + [At start, exactly once.] + + An encrypted document, encoded in base64. The plaintext value is + the 32-byte value SEED_i for this TR. The encryption is as + specified in section 5 below, with STRING_CONSTANT set to + "privctr-seed-v1". + + "d" SP Keyword SP Integer + + [Any number of times] + + For each counter, the name of the counter, and the obfuscated Y + coordinate of this TR's share for that counter. (The Y coordinate + is calculated as y-CTR_c as in 3.1 above.) The order of counters + must correspond to the order used when generating the MASK() values; + different clients do not need to choose the same order. + +5. Hybrid encryption + + This scheme is taken from rend-spec-v3.txt, section 2.5.3, replacing + "secret_input" and "STRING_CONSTANT". It is a hybrid encryption + method for encrypting a message to a curve25519 public key PK. + + We generate a new curve25519 keypair (sk,pk). + + We run the algorithm of rend-spec-v3.txt 2.5.3, replacing + "secret_input" with Curve25519(sk,PK) | SigningKey, where + SigningKey is the DC's signing key. (Including the DC's SigningKey + here prevents one DC from replaying another one's data.) + + We transmit the encrypted data as in rend-spec-v3.txt 2.5.3, + prepending pk. + + +Appendix A. Shamir secret sharing for the impatient + + In Shamir secret sharing, you want to split a value in a finite + field into N shares, such that any K of the N shares can + reconstruct the original value, but K-1 shares give you no + information at all. + + The key insight here is that you can reconstruct a K-degree + polynomial given K+1 distinct points on its curve, but not given + K points. + + So, to split a secret, we going to generate a (K-1)-degree + polynomial. We'll make the Y intercept of the polynomial be our + secret, and choose all the other coefficients at random from our + field. + + Then we compute the (x,y) coordinates for x in [1, N]. Now we + have N points, any K of which can be used to find the original + polynomial. + + Moreover, we can do what PrivCount wants here, because adding the + y coordinates of N shares gives us shares of the sum: If P1 is + the polynomial made to share secret A and P2 is the polynomial + made to share secret B, and if (x,y1) is on P1 and (x,y2) is on + P2, then (x,y1+y2) will be on P1+P2 ... and moreover, the y + intercept of P1+P2 will be A+B. + + To reconstruct a secret from a set of shares, you have to either + go learn about Lagrange polynomials, or just blindly copy a + formula from your favorite source. + + Here is such a formula, as pseudocode^Wpython, assuming that + each share is an object with a _x field and a _y field. + + def interpolate(shares): + for sh in shares: + product_num = FE(1) + product_denom = FE(1) + for sh2 in shares: + if sh2 is sh: + continue + product_num *= sh2._x + product_denom *= (sh2._x - sh._x) + + accumulator += (sh._y * product_num) / product_denom + + return accumulator + + +Appendix B. An alternative way to pick X coordinates + + Above we describe a system where everybody knows the same TRs and + puts them in the same order, and then does Shamir secret sharing + using "x" as the x coordinate for the x'th TR. + + But what if we remove that requirement by having x be based on a hash + of the public key of the TR? Everything would still work, so long as + all users chose the same K value. It would also let us migrate TR + sets a little more gracefully. + + +Appendix C. Sampling floating-point Gaussian noise for differential privacy + + Background: + + When we add noise to a counter value (signal), we want the added noise to + protect all of the bits in the signal, to ensure differential privacy. + + But because noise values are generated from random double(s) using + floating-point calculations, the resulting low bits are not distributed + evenly enough to ensure differential privacy. + + As implemented in the C "double" type, IEEE 754 double-precision + floating-point numbers contain 53 significant bits in their mantissa. This + means that noise calculated using doubles can not ensure differential + privacy for client activity larger than 2**53: + * if the noise is scaled to the magnitude of the signal using + multiplication, then the low bits are unprotected, + * if the noise is not scaled, then the high bits are unprotected. + + But the operations in the noise transform also suffer from floating-point + inaccuracy, further affecting the low bits in the mantissa. So we can only + protect client activity up to 2**46 with Laplacian noise. (We assume that + the limit for Gaussian noise is similar.) + + Our noise generation procedure further reduces this limit to 2**42. For + byte counters, 2**42 is 4 Terabytes, or the observed bandwidth of a 1 Gbps + relay running at full speed for 9 hours. It may be several years before we + want to protect this much client activity. However, since the mitigation is + relatively simple, we specify that it MUST be implemented. + + Procedure: + + Data collectors MUST sample noise as follows: + 1. Generate random double(s) in [0, 1] that are integer multiples of + 2**-53. + TODO: the Gaussian transform in step 2 may require open intervals + 2. Generate a Gaussian floating-point noise value at random with sigma 1, + using the random double(s) generated in step 1. + 3. Multiply the floating-point noise by the floating-point sigma value. + 4. Truncate the scaled noise to an integer to remove the fractional bits. + (These bits can never correspond to signal bits, because PrivCount only + collects integer counters.) + 5. If the floating-point sigma value from step 3 is large enough that any + noise value could be greater than or equal to 2**46, we need to + randomise the low bits of the integer scaled noise value. (This ensures + that the low bits of the signal are always hidden by the noise.) + + If we use the sample_unit_gaussian() transform in nickm/privcount_nm: + A. The maximum r value is sqrt(-2.0*ln(2**-53)) ~= 8.57, and the + maximal sin(theta) values are +/- 1.0. Therefore, the generated + noise values can be greater than or equal to 2**46 when the sigma + value is greater than 2**42. + B. Therefore, the number of low bits that need to be randomised is: + N = floor(sigma / 2**42) + C. We randomise the lowest N bits of the integer noise by replacing them + with a uniformly distributed N-bit integer value in 0...(2**N)-1. + 6. Add the integer noise to the integer counter, before the counter is + incremented in response to events. (This ensures that the signal value + is always protected.) + + This procedure is security-sensitive: changing the order of + multiplications, truncations, or bit replacements can expose the low or + high bits of the signal or noise. + + As long as the noise is sampled using this procedure, the low bits of the + signal are protected. So we do not need to "bin" any signals. + + The impact of randomising more bits than necessary is minor, but if we fail + to randomise an unevenly distributed bit, client activity can be exposed. + Therefore, we choose to randomise all bits that could potentially be affected + by floating-point inaccuracy. + + Justification: + + Although this analysis applies to Laplacian noise, we assume a similar + analysis applies to Gaussian noise. (If we add Laplacian noise on DCs, + the total ends up with a Gaussian distribution anyway.) + + TODO: check that the 2**46 limit applies to Gaussian noise. + + This procedure results in a Gaussian distribution for the higher ~42 bits + of the noise. We can safely ignore the value of the lower bits of the noise, + because they are insignificant for our reporting. + + This procedure is based on section 5.2 of: + "On Significance of the Least Significant Bits For Differential Privacy" + Ilya Mironov, ACM CCS 2012 + https://www.microsoft.com/en-us/research/wp-content/uploads/2012/10/lsbs.pdf + + We believe that this procedure is safe, because we neither round nor smooth + the noise values. The truncation in step 4 has the same effect as Mironov's + "safe snapping" procedure. Randomising the low bits removes the 2**46 limit + on the sigma value, at the cost of departing slightly from the ideal + infinite-precision Gaussian distribution. (But we already know that these + bits are distributed poorly, due to floating-point inaccuracy.) + + Mironov's analysis assumes that a clamp() function is available to clamp + large signal and noise values to an infinite floating-point value. + Instead of clamping, PrivCount's arithmetic wraps modulo P. We believe that + this is safe, because any reported values this large will be meaningless + modulo P. And they will not expose any client activity, because "modulo P" + is an arithmetic transform of the summed noised signal value. + + Alternatives: + + We could round the encrypted value to the nearest multiple of the + unprotected bits. But this relies on the MASK() value being a uniformly + distributed random value, and it is less generic. + + We could also simply fail when we reach the 2**42 limit on the sigma value, + but we do not want to design a system with a limit that low. + + We could use a pure-integer transform to create Gaussian noise, and avoid + floating-point issues entirely. But we have not been able to find an + efficient pure-integer Gaussian or Laplacian noise transform. Nor do we + know if such a transform can be used to ensure differential privacy. + + +Appendix D. Scaling large counters + + We do not believe that scaling will be necessary to collect PrivCount + statistics in Tor. As of November 2017, the Tor network advertises a + capacity of 200 Gbps, or 2**51 bytes per day. We can measure counters as + large as ~2**61 before reaching the P/2 counter limit. + + If scaling becomes necessary, we can scale event values (and noise sigmas) + by a scaling factor before adding them to the counter. Scaling may introduce + a bias in the final result, but this should be insignificant for reporting. + + +Appendix Z. Remaining client-side uncertainties + + [These are the uncertainties at the client side. I'm not considering + TR-only operations here unless they affect clients.] + + Should we do a multi-level thing for the signing keys? That is, have + an identity key for each TR and each DC, and use those to sign + short-term keys? + + How to tell the DCs the parameters of the system, including: + - who the TRs are, and what their keys are? + - what the counters are, and how much noise to add to each? + - how do we impose a delay when the noise parameters change? + (this delay ensures differential privacy even when the old and new + counters are compared) + - or should we try to monotonically increase counter noise? + - when the collection intervals start and end? + - what happens in networks where some relays report some counters, and + other relays report other counters? + - do we just pick the latest counter version, as long as enough relays + support it? + (it's not safe to report multiple copies of counters) + + How the TRs agree on which DCs' counters to collect? + + How data is uploaded to DCs? + + What to say about persistence on the DC side?

1 0

[stem/master] Add support for ADD_ONION's MaxStreamsCloseCircuit
by atagar＠torproject.org 01 Dec '17

01 Dec '17

commit 1ffcb598f780ae80b10cc66f7a89cf1d2c6a301c Author: Damian Johnson <atagar(a)torproject.org> Date: Fri Dec 1 09:33:00 2017 -0800 Add support for ADD_ONION's MaxStreamsCloseCircuit Adding support for a newly documented Onion Service capability... https://gitweb.torproject.org/torspec.git/commit/?id=2fcb1c2 https://trac.torproject.org/projects/tor/ticket/24201 --- docs/change_log.rst | 4 ++++ stem/control.py | 16 +++++++++++++++- stem/version.py | 2 ++ 3 files changed, 21 insertions(+), 1 deletion(-) diff --git a/docs/change_log.rst b/docs/change_log.rst index 191290e1..cfe5200e 100644 --- a/docs/change_log.rst +++ b/docs/change_log.rst @@ -44,6 +44,10 @@ Unreleased The following are only available within Stem's `git repository <download.html>`_. + * **Controller** + + * Added support for limiting the maximum number of streams to :func:`~stem.control.Controller.create_ephemeral_hidden_service` (:spec:`2fcb1c2`) + .. _version_1.6: Version 1.6 (November 5th, 2017) diff --git a/stem/control.py b/stem/control.py index 1468e6c2..1b719dd0 100644 --- a/stem/control.py +++ b/stem/control.py @@ -2804,7 +2804,7 @@ class Controller(BaseController): return [r for r in result if r] # drop any empty responses (GETINFO is blank if unset) - def create_ephemeral_hidden_service(self, ports, key_type = 'NEW', key_content = 'BEST', discard_key = False, detached = False, await_publication = False, basic_auth = None): + def create_ephemeral_hidden_service(self, ports, key_type = 'NEW', key_content = 'BEST', discard_key = False, detached = False, await_publication = False, basic_auth = None, max_streams = None): """ Creates a new hidden service. Unlike :func:`~stem.control.Controller.create_hidden_service` this style of @@ -2862,6 +2862,9 @@ class Controller(BaseController): 'HiddenServiceSingleHopMode 1' and 'HiddenServiceNonAnonymousMode 1' in your torrc. + .. versionchanged:: 1.7.0 + Added the max_streams argument. + :param int,list,dict ports: hidden service port(s) or mapping of hidden service ports to their targets :param str key_type: type of key being provided, generates a new key if @@ -2875,6 +2878,8 @@ class Controller(BaseController): :param bool await_publication: blocks until our descriptor is successfully published if **True** :param dict basic_auth: required user credentials to access this service + :param int max_streams: maximum number of streams the hidden service will + accept, unlimited if zero or not set :returns: :class:`~stem.response.add_onion.AddOnionResponse` with the response @@ -2908,6 +2913,12 @@ class Controller(BaseController): flags.append('BasicAuth') + if max_streams is not None: + if self.get_version() < stem.version.Requirement.ADD_ONION_MAX_STREAMS: + raise stem.UnsatisfiableRequest(message = 'Limitation of the maximum number of streams to accept was added to ADD_ONION in tor version %s' % stem.version.Requirement.ADD_ONION_MAX_STREAMS) + + flags.append('MaxStreamsCloseCircuit') + if self.get_version() >= stem.version.Requirement.ADD_ONION_NON_ANONYMOUS: if self.get_conf('HiddenServiceSingleHopMode', None) == '1' and self.get_conf('HiddenServiceNonAnonymousMode', None) == '1': flags.append('NonAnonymous') @@ -2915,6 +2926,9 @@ class Controller(BaseController): if flags: request += ' Flags=%s' % ','.join(flags) + if max_streams is not None: + request += ' MaxStreams=%s' % max_streams + if isinstance(ports, int): request += ' Port=%s' % ports elif isinstance(ports, list): diff --git a/stem/version.py b/stem/version.py index 5f7822ba..6af239b0 100644 --- a/stem/version.py +++ b/stem/version.py @@ -66,6 +66,7 @@ easily parsed and compared, for instance... **ADD_ONION** ADD_ONION and DEL_ONION requests **ADD_ONION_BASIC_AUTH** ADD_ONION supports basic authentication **ADD_ONION_NON_ANONYMOUS** ADD_ONION supports non-anonymous mode + **ADD_ONION_MAX_STREAMS** ADD_ONION support for MaxStreamsCloseCircuit **LOADCONF** LOADCONF requests **MICRODESCRIPTOR_IS_DEFAULT** Tor gets microdescriptors by default rather than server descriptors **SAVECONF_FORCE** Added the 'FORCE' flag to SAVECONF @@ -382,6 +383,7 @@ Requirement = stem.util.enum.Enum( ('ADD_ONION', Version('0.2.7.1-alpha')), ('ADD_ONION_BASIC_AUTH', Version('0.2.9.1-alpha')), ('ADD_ONION_NON_ANONYMOUS', Version('0.2.9.3-alpha')), + ('ADD_ONION_MAX_STREAMS', Version('0.2.7.2-alpha')), ('LOADCONF', Version('0.2.1.1')), ('MICRODESCRIPTOR_IS_DEFAULT', Version('0.2.3.3')), ('SAVECONF_FORCE', Version('0.3.1.1-alpha')),

1 0

[atlas/master] Compatibility fixes for Internet Explorer 11
by irl＠torproject.org 01 Dec '17

01 Dec '17

commit d081c09b15ed15ba497520f3216aa13d3060f7c9 Author: Iain R. Learmonth <irl(a)fsfe.org> Date: Fri Dec 1 17:31:13 2017 +0000 Compatibility fixes for Internet Explorer 11 --- css/style.css | 2 +- index.html | 2 +- js/collections/aggregates.js | 19 +++++++++++++++---- js/models/relay.js | 2 +- 4 files changed, 18 insertions(+), 7 deletions(-) diff --git a/css/style.css b/css/style.css index 6770c84..2652faf 100644 --- a/css/style.css +++ b/css/style.css @@ -7,7 +7,7 @@ body { background-image:none !important; } body #wrapper { - display:initial !important; + display:block !important; } diff --git a/index.html b/index.html index 283c208..a25f240 100644 --- a/index.html +++ b/index.html @@ -143,7 +143,7 @@ <div class="input-group add-on"> <input class="form-control" placeholder="Search" name="secondary-search-query" id="secondary-search-query" type="text" autocorrect="off" autocapitalize="none"> <div class="input-group-btn"> - <button class="btn btn-danger" id="secondary-search-clear" type="button" title="Clear Search Query"><i class="glyphicon glyphicon-remove-circle"></i></span> + <button class="btn btn-danger" id="secondary-search-clear" type="button" title="Clear Search Query"><i class="glyphicon glyphicon-remove-circle"></i></button> <button class="btn btn-primary" id="secondary-search-submit" type="submit" title="Perform Search"><i class="glyphicon glyphicon-search"></i></button> <button class="btn btn-secondary" id="secondary-search-aggregate" type="button" title="Perform Aggregated Search"><i class="fa fa-compress"></i></button> </div> diff --git a/js/collections/aggregates.js b/js/collections/aggregates.js index 1161ff4..163d7fb 100644 --- a/js/collections/aggregates.js +++ b/js/collections/aggregates.js @@ -87,15 +87,26 @@ define([ error(0); return false; } - _.each(Object.values(aggregates), function(aggregate) { + var aggregatesArr = []; + _.each(Object.keys(aggregates), function(aggregateKey) { + var aggregate = aggregates[aggregateKey]; if ((typeof aggregate.as) !== "string") { - if (aggregate.as.size == 1) aggregate.as = Array.from(aggregate.as.values())[0]; + if (aggregate.as.size == 1) { + aggregate.as.forEach(function(value1, value2, set) { + aggregate.as = value1; + }); + } } if ((typeof aggregate.country) !== "string") { - if (aggregate.country.size == 1) aggregate.country = Array.from(aggregate.country.values())[0]; + if (aggregate.country.size == 1) { + aggregate.country.forEach(function(value1, value2, set) { + aggregate.country = value1; + }); + } } + aggregatesArr.push(aggregate); }); - collection[options.add ? 'add' : 'reset'](Object.values(aggregates), options); + collection[options.add ? 'add' : 'reset'](aggregatesArr, options); success(err, relaysPublished, bridgesPublished); }).fail(function(jqXHR, textStatus, errorThrown) { if(jqXHR.statusText == "error") { diff --git a/js/models/relay.js b/js/models/relay.js index f0a660f..1204544 100644 --- a/js/models/relay.js +++ b/js/models/relay.js @@ -201,7 +201,7 @@ define([ relay.or_addresses = new_addresses; } relay.or_address = relay.or_addresses ? relay.or_addresses[0].split(":")[0] : null; - relay.or_v6_addresses = $.grep(relay.or_addresses, function(n, i) { return n.startsWith("["); }); + relay.or_v6_addresses = $.grep(relay.or_addresses, function(n, i) { return n.indexOf("[") == 0; }); relay.or_port = relay.or_addresses ? relay.or_addresses[0].split(":")[1] : 0; relay.dir_port = relay.dir_address ? relay.dir_address.split(":")[1] : 0; relay.exit_addresses = relay.exit_addresses ? relay.exit_addresses : null;

1 0

[tor/release-0.3.2] Merge branch 'maint-0.3.0' into maint-0.3.1
by nickm＠torproject.org 01 Dec '17

01 Dec '17

commit 5c03bb7c0ca55a17dae64d4a9d05dd88b3d712c8 Merge: 7fae562a4 3bca705c5 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Dec 1 12:13:40 2017 -0500 Merge branch 'maint-0.3.0' into maint-0.3.1 changes/bug24480 | 3 +++ src/or/rendservice.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)

1 0

[tor/release-0.3.2] Merge branch 'maint-0.2.9' into maint-0.3.0
by nickm＠torproject.org 01 Dec '17

01 Dec '17

commit 3bca705c544bd56ade5a25022b51d395f038444f Merge: 6e3ec8222 953a8f851 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Dec 1 12:13:40 2017 -0500 Merge branch 'maint-0.2.9' into maint-0.3.0 changes/bug24480 | 3 +++ src/or/rendservice.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)

1 0

[tor/release-0.3.2] Merge branch 'maint-0.3.1' into maint-0.3.2
by nickm＠torproject.org 01 Dec '17

01 Dec '17

commit b86c9acac360c23749f007c29f1bdd7b8347c18d Merge: 909c91049 5c03bb7c0 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Dec 1 12:13:40 2017 -0500 Merge branch 'maint-0.3.1' into maint-0.3.2 changes/bug24480 | 3 +++ src/or/rendservice.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)

1 0

[tor/release-0.3.2] Merge branch 'maint-0.2.8' into maint-0.2.9
by nickm＠torproject.org 01 Dec '17

01 Dec '17

commit 953a8f851081e6157e9296186c296ab10106b7eb Merge: 495db72c1 f97f301b5 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Dec 1 12:13:40 2017 -0500 Merge branch 'maint-0.2.8' into maint-0.2.9 changes/bug24480 | 3 +++ src/or/rendservice.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)

1 0

[tor/release-0.3.2] Merge branch 'maint-0.3.2' into release-0.3.2
by nickm＠torproject.org 01 Dec '17

01 Dec '17

commit fe12c9756aa6c3ba6f943ea2549dc8a8888b3332 Merge: e0d1ab417 b86c9acac Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Dec 1 12:13:40 2017 -0500 Merge branch 'maint-0.3.2' into release-0.3.2 changes/bug24480 | 3 +++ src/or/rendservice.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)

1 0

[tor/release-0.3.2] Merge branch 'maint-0.2.5' into maint-0.2.8
by nickm＠torproject.org 01 Dec '17

01 Dec '17

commit f97f301b5b5605f559522ffae2159fc4d061817c Merge: dc3890439 461e34bb3 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Dec 1 12:13:39 2017 -0500 Merge branch 'maint-0.2.5' into maint-0.2.8 changes/bug24480 | 3 +++ src/or/rendservice.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)

1 0