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

[translation/torcheck] Update translations for torcheck
by translation＠torproject.org 02 Dec '17

02 Dec '17

commit 2fd3919a6aaeedc38243100bc057dad3cdde744d Author: Translation commit bot <translation(a)torproject.org> Date: Sat Dec 2 09:15:15 2017 +0000 Update translations for torcheck --- ms_MY/torcheck.po | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/ms_MY/torcheck.po b/ms_MY/torcheck.po index 15c435ced..eb21ef989 100644 --- a/ms_MY/torcheck.po +++ b/ms_MY/torcheck.po @@ -2,6 +2,7 @@ # Copyright (C) 2008-2013 The Tor Project, Inc # # Translators: +# abuyop <abuyop(a)gmail.com>, 2017 # kz_gtr <kz_gtr(a)yahoo.com>, 2014 # Mohd Shahril Bin Zainol Abidin <mohd_shahril_96(a)yahoo.com>, 2013 # Weldan Jamili <mweldan(a)gmail.com>, 2012 @@ -9,8 +10,8 @@ msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "POT-Creation-Date: 2012-02-16 20:28+PDT\n" -"PO-Revision-Date: 2017-09-19 12:58+0000\n" -"Last-Translator: runasand <inactive+runasand(a)transifex.com>\n" +"PO-Revision-Date: 2017-12-02 09:00+0000\n" +"Last-Translator: abuyop <abuyop(a)gmail.com>\n" "Language-Team: Malay (Malaysia) (http://www.transifex.com/otf/torproject/language/ms_MY/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -29,7 +30,7 @@ msgid "" msgstr "Sila rujuk kepada laman web <a href=\"https://www.torproject.org/\">Tor</ a> untuk maklumat lanjut mengenai penggunaan Tor dengan selamat. Anda kini bebas untuk melayari internet tanpa nama ." msgid "There is a security update available for Tor Browser." -msgstr "" +msgstr "Terdapat kemaskini keselamatan yang tersedia untuk Pelayar Tor." msgid "" "<a href=\"https://www.torproject.org/download/download-easy.html\">Click " @@ -72,34 +73,34 @@ msgid "" msgstr "Projek Tor dibawah US 501(c)(3) adalah organisasi bukan keuntungan yang khusus untuk penyelidikan, pembangunan dan pendidikan dalam talian secara lebih selamat dan menguatkan privasi." msgid "Learn More »" -msgstr "" +msgstr "Ketahui Lebih Lanjut »" msgid "Go" msgstr "Pergi" msgid "Short User Manual" -msgstr "" +msgstr "Panduan Pengguna Ringkas" msgid "Donate to Support Tor" -msgstr "" +msgstr "Dermalah untuk Sokong PembangunanTor" msgid "Tor Q&A Site" -msgstr "" +msgstr "Laman S&J Tor" msgid "Volunteer" msgstr "Sukarela" msgid "JavaScript is enabled." -msgstr "" +msgstr "Srkip Java dibenarkan." msgid "JavaScript is disabled." -msgstr "" +msgstr "Srkip Java dilumpuhkan." msgid "However, it does not appear to be Tor Browser." -msgstr "" +msgstr "Walaubagaimanapun, ia bukanlah Pelayar Tor." msgid "Run a Relay" -msgstr "" +msgstr "Jalankan Pengganti" msgid "Stay Anonymous" -msgstr "" +msgstr "Kekal Awanama"

1 0

[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