August 2017 - tor-dev - lists.torproject.org

non-anonymous ephemeral onion services with stem
by Micah Lee 30 Jan '18

30 Jan '18

The stem documentation for create_ephemeral_hidden_service [1] says: "Changed in version 1.5.0: Added support for non-anonymous services." But I can't figure out to actually use this feature. There doesn't seem to be a new argument to say if you want your onion service to be non-anonymous. It also says, "Changed in version 1.5.0: Added the basic_auth argument." But there's a new basic_auth argument you can pass into the function to use that. [1] https://stem.torproject.org/api/control.html#stem.control.Controller.create…

5 12

onionoo.tpo stuck at 2017-06-12 12:00?
by nusenu 26 Oct '17

26 Oct '17

Hi, just wanted to let you know that the delta between relays_published and current time is unusually high. https://onionoo.torproject.org/details?limit=0 {"version":"4.0", "relays_published":"2017-06-12 12:00:00", -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

2 4

Pluggable Transports 2.0 Specification, Draft 2
by Brandon Wiley 10 Oct '17

10 Oct '17

Attached is the second draft of the Pluggable Transport 2.0 Specification. If you have feedback on this draft, please send me your comments by July 20.

4 11

PQ crypto updates
by bancfc＠openmailbox.org 18 Sep '17

18 Sep '17

If I understand correctly, DJB describes how NTRU-Prime is more robust against certain attack classes that Ring-LWE is more prone to: https://twitter.com/hashbreaker/status/880086983057526784 *** About two months later DJB releases a streamlined version of NTRU-Prime that is faster, safer and uses less resources than the latest version of New Hope while (wait for it...) completely eliminating decryption failures !: https://twitter.com/hashbreaker/status/898048057849380864 https://twitter.com/hashbreaker/status/898048506681860096 https://twitter.com/hashbreaker/status/898048760009420801 https://twitter.com/hashbreaker/status/898391210456489984 *** Boom headshot! AEZ is dead in the water post quantum: Paper name: Quantum Key-Recovery on full AEZ https://eprint.iacr.org/2017/767.pdf

5 8

Dir auths using 2x bandwidth in last week
by Roger Dingledine 18 Sep '17

18 Sep '17

https://atlas.torproject.org/#details/9695DFC35FFEB861329B9F1AB04C46397020C… https://atlas.torproject.org/#details/F2044413DAC2E02E3D6BCF4735A19BCA1DE97… https://atlas.torproject.org/#details/BD6A829255CB08E66FBE7D3748363586E46B3… https://atlas.torproject.org/#details/74A910646BCEEFBCD2E874FC1DC997430F968… https://atlas.torproject.org/#details/7EA6EAD6FD83083C538F44038BBFA077587DD… all show a big increase in sent bytes starting at the end of July. It isn't growth in Tor users, since those have stayed relatively flat in the last two weeks. And the new rate seems to be the new normal -- it's showing no signs of going back to the old rate. I would assume it's outgoing directory stuff, since that's most of what dir auths do. Any guesses? --Roger

3 6

Proposal 280: Privacy-Preseving Statistics with Privcount in Tor
by Nick Mathewson 13 Sep '17

13 Sep '17

Hi! Tim helped me write this this draft last week, and I shared it with the PrivCount authors. I've already gotten some good comments from Aaron, which I'll repost in a followup message, with his permission. ================================ Filename: 280-privcount-in-tor.txt Title: Privacy-Preseving Statistics with Privcount in Tor Author: Nick Mathewson, Tim Wilson-Brown Created: 02-Aug-2017 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 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. All values in the scheme below are 64-bit unsigned integers; addition and subtraction are modulo 2^64. In PrivCount, a Data Collector (in this case a Tor relay) shares numeric data with N different Tally Reporters. (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.) To share data, for each value X to be shared, the relay generates random values B_1 though B_n, and shares each B_i secretly with a single Tally Reporter. The relay then publishes Y = X + SUM(B_i) + Z, where Z is a noise value taken at random from a gaussian distribution. The Tally Reporters can reconstruct X+Z by securely computing SUM(B_i) across all contributing Data Collectors. (Tally Reporters MUST NOT share individual B_i values: that would expose the underlying relay totals.) In order to prevent bogus data from corrupting the tally, the Tor relays and the Tally Reporters perform multiple "instances" of this algorithm, randomly sampling in each relays. The relay sends multiple Y values for each measurement, built with different sets of B_i. These "instances" are numbered in order from 1 to R. So that the system will still produce results in the event of a single Tally Reporter failure, these instances are distributed across multiple subsets of Tally Reporters. Below we describe a data format for this. 3. The document format 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 two kinds of documents here: a "counters" document that publishes all the Y values, and a "blinding" document that describes the B_i values. But see "An optimized alternative" below. 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. [[[TODO: Do we need a counter version as well? Noise is distributed across a particular set of counters, to provide differential privacy guarantees for those counters. Reducing noise requires a break in the collection. Adding counters is ok if the noise on each counter monotonically increases. (Removing counters always reduces noise.) We also need to work out how to handle instances with mixed Tor versions, where some Data Collectors report different counters to other Data Collectors. (The blinding works if we substitute zeroes for missing counters on Tally Reporters. But we also need to add noise in this case.) -teor ]]] "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. "num-instances" SP Number [Exactly once] The number of "instances" that the relay used (see above.) "tally-reporter" SP Identifier SP Key SP InstanceNumbers [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 InstanceNumbers are comma-separated lists of decimal integers from 0 to (num-instances - 1), in ascending order. Keyword ":" SP Int SP Int SP Int ... [Any number of times] The Y values for a single measurement. There are num-instances such Y values for each measurement. They are 64-bit unsigned integers, expressed in decimal. The "Keyword" denotes which measurement is being shared. Keyword MAY be any sequence of characters other than colon, nul, space, and newline, though implementators SHOULD avoid getting too creative here. Keywords MUST be unique within a single document. Tally Reporters MUST handle unrecognized keywords. Keywords MAY appear in any order. It is safe to send the blinded totals for each instance to every Tally Reporter. To unblind the totals, a Tally Reporter needs: * a blinding document from each relay in the instance, and * the per-counter blinding sums from the other Tally Reporters in their instance. [[[TODO: But is it safer to create a per-instance counters document? -- teor]]] The semantics of individual measurements are not specified here. "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. The "blinding" document has these elements: "privctr-secret-offsets" SP VERSION SP SigningKey [At start, exactly once.] The VERSION and SigningKey parameters are the same as for "privctr-dump-format". "instances" SP Numbers [Exactly once] The instances that this Tally Reporter handles. They are given as comma-separated decimal integers, as in the "tally-reporter" entry in the counters document. They MUST match the instances listed in the counters document. [[[TODO: this is redundant. Specify the constraint instead? --teor]]] "num-counters" SP Number [Exactly once] The number of counters that the relay used in its counters document. This MUST be equal to the number of keywords in the counters document. [[[TODO: this is redundant. Specify the constraint instead? --teor]]] "tally-reporter-pubkey" SP Key [Exactly once] The curve25519 public key of the tally reporter who is intended to receive an decrypt this document. The key is base64-encoded with padding stripped. "count-document-digest" SP "sha3" Digest NL "-----BEGIN ENCRYPTED DATA-----" NL Data "-----END ENCRYPTED DATA-----" NL [Exactly once] The SHA3-256 digest of the count document corresponding to this blinding document. The digest is base64-encoded with padding stripped. The data encodes the blinding values (See "The Blinding Values") below, and is encrypted to the tally reporter's public key using the hybrid encryption algorithm described below. "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. The Blinding Values The "Data" field of the blinding documents above, when decrypted, yields a sequence of 64-bit binary values, encoded in network (big-endian) order. There are C * R such values, where C is the number of keywords in the count document, and R is the number of instances that the Tally Reporter participates in. The client generates all of these values uniformly at random. For each keyword in the count document, in the order specified by the count document, the decrypted data holds R*8 bytes for the specified instance of that keyword's blinded counter. For example: if the count document lists the keywords "b", "x", "g", and "a" (in that order), and lists instances "0", and "2", then the decrypted data will hold the blinding values in this order: b, instance 0 b, instance 2 x, instance 0 x, instance 2 g, instance 0 g, instance 2 a, instance 0 a, instance 2 4. Implementation Notes A relay should, when starting a new round, generate all the blinding values and noise values in advance. The relay should then use these values to compute Y_0 = SUM(B_i) + Z for each instance of each counter. Having done this, the relay MUST encrypt the blinding values to the public key of each tally reporter, and wipe them from memory. 5. The hybrid encryption algorithm We use a hybrid encryption scheme above, where items can be encrypted to a public key. We instantiate it as follows, using curve25519 public keys. To encrypt a plaintext M to a public key PK1 1. the sender generates a new ephemeral keypair sk2, PK2. 2. The sender computes the shared diffie hellman secret SEED = (sk2 * PK1). 3. The sender derives 64 bytes of key material as SHAKE256(TEXT | SEED)[...64] where "TEXT" is "Expand curve25519 for privcount encryption". The first 32 bytes of this is an aes key K1; the second 32 bytes are a mac key K2. 4. The sender computes a ciphertext C as AES256_CTR(K1, M) 5. The sender computes a MAC as SHA3_256([00 00 00 00 00 00 00 20] | K2 | C) 6. The hybrid-encrypted text is PK2 | MAC | C. 6. An optimized alternative As an alternative, the sequences of blinding values is NOT transmitted to the tally reporters. Instead the client generates a single ephemeral keypair sk_c, PK_c, and places the public key in its counts document. It does this each time a new round begins. For each tally reporter with public key PK_i, the client then does the handshake sk_c * PK_i to compute SEED_i. The client then generates the blinding values for that tally reporter as SHAKE256(SEED_i)[...R*C*8]. After initializing the counters to Y_0, the client can discard the blinding values and sk_c. Later, the tally reporters can reconstruct the blinding values as SHAKE256(sk_i * PK_c)[...] This alternative allows the client to transmit only a single public key, when previously it would need to transmit a complete set of blinding factors for each tally reporter. Further, the alternative does away with the need for blinding documents altogether. It is, however, more sensitive to any defects in SHAKE256 than the design above. Like the rest of this design, it would need rethinking if we want to expand this scheme to work with anonymous data collectors, such as Tor clients.

3 4

[release] [protocol] Onionoo 4.1-1.4.1
by iwakeh 31 Aug '17

31 Aug '17

Hi there! Onionoo's protocol was extended and has a minor version jump to 4.1, therefore a new release is available: https://dist.torproject.org/onionoo/4.1-1.4.1/ Protocol changes (also summarized in [0]): * removal of (unused) beta fields in bridge client objects * addition of a new search filter parameter by Tor version, see [1] and [2] for example calls. There were also some internal improvements, which can be found in the changelog [3a]. You might have noticed an increment in the middle and minor application version. This is due to a fix for the new filter, which was discovered after creating the 4.1-1.4.0 release, but could be applied before announcing 4.1-1.4.0 (cf.[3b]). Please direct comments and questions to the metrics-team mailing list [4]. Cheers, iwakeh [0] https://metrics.torproject.org/onionoo.html#versions [1] https://onionoo.torproject.org/details?search=version:0.2.4&limit=10 [2] https://onionoo.torproject.org/details?search=version:0.3&limit=10 [3a] https://gitweb.torproject.org/onionoo.git/tree/CHANGELOG.md?h=onionoo-4.1-1… [3b] https://gitweb.torproject.org/onionoo.git/tree/CHANGELOG.md?h=onionoo-4.1-1… [4] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

Meeting on IRC to discuss prop280 privcount stuff (Sep 12, 8pm EDT)
by Nick Mathewson 28 Aug '17

28 Aug '17

Hello! On #tor-dev at 8pm EDT on Tuesday Sep 12 (== 00:00 Sep 13 in UTC, I think), we'll have an IRC meeting to talk about proposal 280, and integrating privcount into Tor. If you're interested, please feel free to drop by! The current draft of the proposal is at https://gitweb.torproject.org/torspec.git/tree/proposals/280-privcount-in-t… best wisehes, -- Nick

1 0

Proposal 281: downloading microdescriptors in bulk
by Nick Mathewson 28 Aug '17

28 Aug '17

Filename: 281-bulk-md-download.txt Title: Downloading microdescriptors in bulk Author: Nick Mathewson Created: 11-Aug-2017 Status: Draft 1. Introduction This proposal describes a ways to download more microdescriptors at a time, using fewer bytes. Right now, to download N microdescriptors, the client must send about 44*N bytes in its HTTP request. Because clients can request microdescriptors in any combination, the directory caches cannot pre-compress responses to these requests, and need to use less space-efficient on-the-fly compression algorithms. Under this proposal, clients simply say "Send me the microdescriptors I need", given what I know. 2. Combined microdescriptor downloads 2.1. By diff If a client has a consensus with base64 sha3-256 digest X, and it previously had a consensus with base64 sha3-256 digests Y then it may request all the microdescriptors listed in X but not Y, by asking for the resource: /tor/micro/diff/X/Y Clients SHOULD only ask for this resource compressed. Caches MUST NOT answer this request unless they recognize the consensus with digest X, and digest Y. digest Y. If answering, caches MUST reply with all of the microdescriptors that the cache holds that were listed by consensus X, and MUST omit all the microdescriptors that were omitted listed in consensus Y. 2.2. By consensus: If a client has fewer than NMNM% of the microdescriptors listed in a consensus X, it should fetch the resource /tor/micro/full/X Clients SHOULD only ask for this resource compressed. Caches MUST NOT answer this request unless they recognize the consensus with digest X. They should send all the microdescriptors they have that are listed in that consensus. 2.3. When to make these requests Clients should decide to use this format in preference to the old download-by-digest format if the consensus X lists their preferred directory cache as using a new DirCache subprotocol version. (See 5 below.) 3. Performance analysis This is a back-of-the-envelope analysis using a month's worth of consensus documents, and a randomly chosen sample of microdescriptors. On average, about 0.5% of the microdescriptors change between any two consensuses. Call it 50. That means 50*43 bytes == 2150 bytes to request the microdescriptors. It means ~24530 bytes of microdescriptors downloaded, compressed to ~13687 bytes by zstd. With this proposal, we're down to 86 bytes for the request, and we can precompute the compressed output, making it save to use lzma2, getting a compressed result more like 13362. It appears that this change would save about 15% for incremental microdescriptor downloads, most of that coming from the reduction in request size. For complete downloads, a complete set of microdescriptors is about 7700 microdesciptors long. That makes the total number of bytes for the requests 7700*43 == 331100 bytes. The response, if compressed with lzma instead of zstd, would fall from 1659682 to 1587804 bytes, for a total savings of 20%. 5. Compatibility Caches supporting this download protocol need to advertise support of a new DirCache subprotocol version.

3 2

Some Tor Devs could get higher pay as PR than as programmers
by Ryan Carboni 25 Aug '17

25 Aug '17

Whenever I read something, with an open mind, but say, in a sandboxed environment (don't run your memes on root), I get impressed by arguments which convince me of things which are not true. Take for instance the following article: https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-… It is a self-contradictory argument, we detected these bad relays when they arrived, allowed them for 6 months. Now, what was the available prophylactic measures at the time? Alleged family greylisting wasn't available at the time, but certainly an attempt could be made to contact (presumably) a few owners of the tor relays. Although it turned out to be only one owner. I mean, people depend their lives on Tor. Can all discretionary decisions of this type be made public? Now there's also the Tor's unlike racists we value free speech. I cannot explain it, but if one replaced racists with Islamists, somehow the argument is weaker. I can't fully explain it, even though I've heard more about beheadings and defenestrations as opposed to... whatever racists do nowadays (shitpost?). It truly is a clever argument that strengthens and preserves Tor's brand identity among target demographic groups. How did Freud invent psychoanalysis? What are you doing during the idle cycles of your brain? One does not need a fancy degree to be an amateur at anything, or do you folks not call yourselves hackers?

2 1