- tor-dev - lists.torproject.org

Call For Testing: Capsicum Integration With Tor
by Shawn Webb 18 Oct '17

18 Oct '17

Tor Capsicum Call For Testing (CFT) =================================== Capsicum is a capabilities framework for FreeBSD and its derivatives. It's commonly used to implement sandboxing. Tor currently supports sandboxing only on Linux, via seccomp-filter. This CFT presents initial Capsicum support for Tor on FreeBSD and HardenedBSD. The work performed is sponsored by HardenedBSD. The source for the Capsicum work can be found at https://github.com/lattera/tor. The branch to use is the hardening/capsicum branch. We hope that this implementation, or a future revision of it, will be merged upstream by the Tor Project. Design and Architecture ----------------------- When capabilities mode (capmode) is entered (ie, the sandbox is enabled), the kernel will prevent Tor from accessing the global namespace. This means that once the sandbox is enabled, Tor will not be able to open files, create sockets, connect outbound, etc. Naturally, applications like Tor needs to be able to create sockets on-demand and at-will. In these situations, it is common to fork a child process which will perform these "privileged" operations. Only the parent process will enter capmode. Communication between the parent and the child is performed via a socketpair descriptor. Wrappers in the parent process call into the child process to perform these privileged operations. Thus, open(2) becomes sandbox_open(), rename(2) becomes sandbox_rename(), and so on. A full list of wrapped operations will be provided further on. When the parent process wants to open a file, it will call sandbox_open. The parent process will tell the child via the socketpair to open the file and limit its capabilities. On success, the child will return the limited file descriptor back to the parent. We prevent race conditions surrounding the limitation of file descriptors by calling cap_rights_limit(2) on the descriptor in the child before passing the descriptor back to the parent. By the time the parent can make use of the descriptor, the descriptor is fully limited to a minimal set of capabilities. Tor's existing sandbox abstraction API relies on a filtering-based approach. We've utilized parts of that API to provide a basic whitelist. Once capmode is entered, the whitelist turns read-only and cannot be modified. Efforts to apply Capsicum in the form of wrappers, such as has been done in this work and others, require ASLR and W^X to be effective. Without ASLR, an attacker could simply craft an exploit to return into the respecive wrapper and bypass any guarantees Capsicum provides. Additionally, Control Flow Integrity (CFI) from clang/llvm will provide forward-edge guarantees. SafeStack from clang/llvm will provide backward-edge guarantees. Known Issues ------------ Enabling the sandbox while having Tor configured in transparent proxy mode is currently broken. We are researching what causes the breakage. Chances are that either Tor is trying to access the global namespace in transparent proxy mode or one or more file descriptors simply need to be granted one or more extra capabilities. Future Work ----------- We plan to research and fix, if possible, the known regression regarding transparent proxying. The read-only nature of the whitelist is only enforced via a logic operation. We plan to relocate the whitelist into a memory mapping that will turn read-only upon entering capmode. The current implementation should be further abstracted in order for Tor to be able to pick at runtime the appropriate sandbox implementation. This would be similar to how Tor chooses which ed25519 implementation to use, donna or ref10. Testing and Reporting Back -------------------------- 1. Install required development tools: # pkg install libevent autoconf automake autotools libtool gmake \ git-lite 2. Clone the git repo: # git clone https://github.com/lattera/tor.git 3. Check out the hardening/capsicum branch: # cd tor # git checkout -b hardening/capsicum origin/hardening/capsicum 4. Regenerate autoconf magic: # ./autogen.sh 5. Run the configure script: # ./configure [custom arguments to configure as you'd prefer] 6. Build and install: # gmake -j$(sysctl -n hw.ncpu) && gmake install 7. Enable the sandbox in the torrc: # echo "Sandbox 1" >> [path to torrc] 8. Run Tor: # tor 9. Report results: Email shawn.webb(a)hardenedbsd.org, report back any issues you may have. If your testing succeeds, I'd like to hear about it, too. Please do not open any tickets regarding this work on the Tor Project's Trac instance. Contact me directly. A sample report back would include a sanitized torrc along with a pass/fail result. A successful result would mean that all features you rely on work as desired. A failed result would mean that enabling a feature results in Tor crashing, erroring out, or exhibiting bugs. If Tor crashes for you, please include a backtrace if possible. New Sandbox Wrappers -------------------- These APIs will need to be used regardless of operating system. On operating systems outside of FreeBSD and HardenedBSD, they are simply macros that forward to their respective native API call. * int sandbox_close(int fd): close(2) wrapper * int sandbox_rename(const char *from, const char *to): rename(2) wrapper * int sandbox_stat(const char *path, struct stat *sb): stat(2) wrapper * int sandbox_mkdir(const char *path, mode_t mode): mkdir(2) wrapper * int sandbox_connect(int sockfd, const struct sockaddr *name, socklen_t namelen): connect(2) wrapper * int sandbox_socket(int domain, int type, int protocol, cap_rights_t *rights): socket(2) wrapper * int sandbox_unlink(const char *path): unlink(2) wrapper * int sandbox_open(const char *path, int flags, mode_t mode, cap_rights_t *rights): open(2) wrapper -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE

1 1

GET request to a regular website using Tor and nodejs
by Fernando Gabrieli 17 Oct '17

17 Oct '17

Hello all, i want to tunnel a http request from my nodejs app through Tor, would you point me in the right direction to start implementing this? thanks in advance Fernando

2 1

Re: [tor-dev] User perception of onion service discovery
by dawuud 15 Oct '17

15 Oct '17

I agree with Alec. Don't block the existing tor2web stuff, that would be very rude. Instead just do not implement any kind of tor2web for v3 onion services so that tor2web will gradually fade as we migrate. > *although speaking as a geek I believe that re-engineering T2W to > support SSL via SNI-Sniffing would address this, it would be a gross > and pointless hack, complicated still further by certificate issuance, > and all reasonable use cases for which would be better addressed by > running a local copy of Tor. Ah yeah, Donncha wrote a tool to do that called oniongateway: https://github.com/DonnchaC/oniongateway Is that what you mean?

1 0

The Tor git master branch is now 0.3.3.x
by Nick Mathewson 15 Oct '17

15 Oct '17

Hello! With the opening of the new 0.3.3.x branch, the git master branch for tor is now 0.3.3.x. Feature patches should still be based on master. If you are writing any bugfix patch that should go into an earlier version, please base it on the appropriate maint branch. For example, if you're fixing a bug in Tor 0.3.2.x, you should base your git branch on the "maint-0.3.2" branch. best wishes, -- Nick

1 0

No network-team IRC meetings this week
by Nick Mathewson 15 Oct '17

15 Oct '17

Hi, all! The usual network-team IRC meeting on Monday, and the usual patch party on Tuesday, will not happen this week: almost everybody will traveling from, or recovering from, the meeting in Montreal. For more information about our regular meetings, please see: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam Remember, new contributors and external developers are always welcome! yrs, -- Nick

1 0

User perception of onion service discovery
by Philipp Winter 15 Oct '17

15 Oct '17

This is the second part of our preliminary analysis of how Tor users interact with onion services [0]. In this part, we analyse the issue of onion service discovery. Onion services are private by default, so it's the operator's responsibility to disseminate their domain if they want it to be public. Question 3.6 in our survey asked: > How do you discover new onion sites? The breakdown looks as follows. Respondents could select multiple answers, so the percentages are based on the total number of respondents. Method Percentage ----------------------------------------------------------------------- >From social networking sites such as Reddit or Twitter 50.67 I browse the list of onion site search engines such as ahmia.fi 50.50 I randomly encounter them while browsing the web 47.65 Recommendations from friends and family 19.46 Other (see below for common themes) 18.12 I am not interested in learning about new onion sites 4.19 The data shows that social networking sites, search engines, and "random encounters" are rather popular. Respondents who selected "Other" mostly brought up onion service lists and aggregators. Following up, question 3.7 then asked: > Are you satisfied with the way you discover new onion sites? 61% selected "Yes" while the remaining 39% selected "No." Some respondents who selected "Yes" brought up that they have no interest in learning about new onion services; in part because they only use Facebook's (or some other) onion service. Among the respondents who selected "No," there are a bunch of reoccurring themes, in no particular order: - The most prominent complaint was about broken links on onion site lists. There is non-trivial churn among onion sites and our respondents were frustrated that existing lists are typically not curated and contain many dead links. - Many respondents were not aware of search engines such as ahmia.fi. Among those that were, many were not satisfied with both the search results and the number of indexed onion sites. Unsurprisingly, a "Google for onion sites" was a frequent wish. - Several respondents were unhappy with existing aggregators. In addition to broken links, some distrust lists because they occasionally contain scam and phishing sites. The difficulty of telling apart two given onion domain names exacerbates this issue. - Some respondents would like aggregators to be more verbose in their description of onion sites. In particular, these respondents were trying to avoid illegal and pornographic content, which is often difficult if the description is vague and the onion domain reveals nothing about its content. - Many respondents expressed frustration about the difficulty of finding out if site X also provides a corresponding onion service. A common wish was to have site X list its onion service prominently in a footer. Ironically, some respondents were surprised that torproject.org has a corresponding onion site -- they couldn't find it on the web site. - Two respondents compared the current state of onion services with the web of the 90s: Few sites existed, they linked to each other only sparsely, and search engines were experimental at best. - Interestingly, some respondents voiced frustration about various usability issues, but mentioned in the same sentence that this is an inherent trade-off of privacy technology, suggesting that there is nothing that can be done about it. There are two potential solutions that would address some of the above issues: - Have next-gen onion services opt-in to a broadcast mechanism that automatically propagates them. Naturally, we would like such a mechanism to be censorship-resistant and built in a way that only the owner of an onion service is authorised to broadcast their service. - Websites could use an HTTP header to announce the existence of a corresponding onion site. This issue was discussed in Feb 2017 over at tor-onions. Someone brought up the Alt-Svc header as a potential solution [1]. In a subsequent survey question we asked if our respondents would appreciate an automatic redirect from a web site to its corresponding onion site. The overall tendency leaned towards "Yes," provided that the implementation is sound and users can override the redirect. Again, it's important to take these results with a grain of salt. Our data has some survivor bias: Presumably, we mostly heard from people who are Tor users despite usability issues. We likely didn't hear from many people who once experimented with Tor or onion services, decided it's not usable enough, and gave up. The above was joint work with my colleagues Marshini Chetty, Annie Edmundson, Nick Feamster, and Laura M. Roberts. [0] <https://nymity.ch/onion-services/> [1] <https://lists.torproject.org/pipermail/tor-onions/2016-February/000045.html>

5 6

non-ASCII handling in tor and onionoo
by nusenu 14 Oct '17

14 Oct '17

Hi, I'm trying to find out if non-ASCII characters are allowed in descriptor data (and what onionoo would do with non-ASCII currently displayed as "?"). According to the spec non-ASCII chars are not allowed: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n218 I searched trac because I remembered there were some ASCII related tickets: https://trac.torproject.org/projects/tor/ticket/1258 closed due to https://trac.torproject.org/projects/tor/ticket/1720 (which has nothing to do with non-ASCII) https://trac.torproject.org/projects/tor/ticket/1270 Is this summary correct? Currently non-ASCII is not compliant with the spec but your consensus is that non-ASCII chars should be supported but no one got around to patch the spec and implementation. thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

2 2

Pluggable Transports 2.0 Specification, Draft 3
by Brandon Wiley 13 Oct '17

13 Oct '17

Below is a link to the third draft of the Pluggable Transport 2.0 Specification. If you have feedback on this draft, please send me your comments by October 31. Thank you! Changes in this version: - Expanded acknowledgements section - thanks Yawning! - Removed TransportConn and TransportListener in favor of net.Conn and net.Listener - Modified SOCKS authentication method to use IANA-assigned designator - Added error response codes for per-connection arguments - Many typos fixed - thanks David Fifield! - Clarified some definitions - thanks teor! Link: https://operatorfoundation.org/PluggableTransportSpecification-v2-Draft3.pdf

1 1

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

Your input on the Tor Metrics Roadmap 2017/18
by Karsten Loesing 10 Oct '17

10 Oct '17

Hello everyone, we, the Tor Metrics Team, are currently drafting a roadmap for the work we'd like to do on in the upcoming 12 months until September 2018. If you believe that you're affected by these plans and want your ideas to be included in this roadmap, please read our current draft and send your feedback either to this list, to the metrics-team@ mailing list, or to iwakeh or irl and/or me directly. https://people.torproject.org/~karsten/volatile/metrics-team-roadmap-2017-1… In particular, we're interested in: - tasks we're missing or that we're listing as long-term goals (Q4/2018 or later) that you think should have higher priority over the tasks we picked for the time until Q3/2018, - tasks that we picked that you think we put in for you or users with similar interests and that you think we could de-prioritize, and - tasks that you'd want to contribute to in any way, in which case we might reach out to you when we start working on them. Thanks for helping to make this roadmap document reflect what really needs to be done to make Tor Metrics better. All the best, Karsten

4 3

[release] CollecTor 1.4.0, metrics-lib 2.1.1, Onionoo 4.2-1.6.0
by iwakeh 10 Oct '17

10 Oct '17

Hi there! three new releases are available: https://dist.torproject.org/collector/1.4.0/ https://dist.torproject.org/onionoo/4.2-1.6.0/ https://dist.torproject.org/metrics-lib/2.1.1/ These releases publish the build revision of the software running on a particular Onionoo or Collector instance. For Onionoo this means an additional field "build_revision" in documents (cf. protocol changes [0]), and CollecTor shows ths field in its index.json [1]. All these changes are already deployed on all tp.o instances. CollecTor now enables sync-ing of OnionPerf measuremnts between instances. As there were changes to CollecTor's configuration file, all operators of CollecTor instances should also update collector.properties on their instance. INSTALL.md gives all details about how to create a new collector.properties configuration file [2]. Other details can be found in the respective change logs [3], [4], [5]. Please direct comments and questions to the metrics-team mailing list [6]. Cheers, iwakeh [0] https://metrics.torproject.org/onionoo.html#versions [1] https://metrics.torproject.org/collector.html#index-json [2] https://gitweb.torproject.org/collector.git/tree/INSTALL.md#n103 [3] https://gitweb.torproject.org/collector.git/tree/CHANGELOG.md?h=collector-1… [4] https://gitweb.torproject.org/metrics-lib.git/tree/CHANGELOG.md?h=metrics-l… [5] https://gitweb.torproject.org/onionoo.git/tree/CHANGELOG.md?h=onionoo-4.2-1… [6] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

PrivCount - Draft of secret-sharing specification
by Carolin Zöbelein 02 Oct '17

02 Oct '17

Hi (PrivCount) folks! I just finished the first draft of the k,n-secret-sharing thing for PrivCount. :) Sorry that it need some time, but I'm sadly a bit slowly with reading and writing. You can find it here at github: https://github.com/Samdney/28X-k-of-n-secret-sharing and also below in this email. You will see a lot of "=> TODO". This belongs of course not to the specification ;). There are still a lot of open details and questions left (or stuff which still have to be written, I think) and hence it is time for some help from you, now. I looked a bit around how a specification has to look like, before I started to write it, but this was more confusing like helpful, hehe. I'm a completely newbie with writing this kind of documents, hence I'm pretty nervous for your feedback :) Bye, Carolin ========== Draft v1 ========== Filename: 28X-k-of-n-secret-sharing.txt Title: k-of-n Secret Sharing Author: Carolin Zöbelein Created: XX-Sept-2017 Status: Draft 0. Motivation The implementation of schemes for collecting statistic data within a high sensitive network like Tor for preserving anonymity, is a hard challenge. Over the years the Tor network has grown but its usage and operation is not well-understood and already existing ways [1] leads to some open issues [maybe add also a reference here]. For doing this better like the current state of the art, we discuss to switch to PrivCount [2][3], a system for measuring the Tor network created with a high attention on user privacy. PrivCount consists of a system of Data Collectors (DC) which forward their blinded measure counter results to a number of, so-called, Tally Reporters (TR) which are only together be able to reconstruct the original data. In the context of the implementation of the mentioned system, we decided to use a secret sharing algorithm for forwarding the blinded counter values. This gives us the chance of reconstructing the data also with a particular minimum amount of secret share holders and hence a failure handling possibility of Tally Reporters. => TODO: References [maybe add also a reference here] 1. Introduction Assume, we have a given secret s which we want to share with a particular number N of participants who are only together be able to reconstruct it. To realize this, we can split our secret in n parts s_i. Our secret will be then the sum over all s_i. This is the simplest secret sharing scheme at all. Since it needs all participants for the reconstruction, it is called a (N,N) treshold secret sharing algorithm. But we also see that it has weaknesses. With every leaked share s_i, an adversary can reduce the number of possible soulutions for our secret very easily. This leads to the group of more efficient secret sharing algorithms. In [4], Adi Shamir introduced a (K,N) secret sharing scheme which is named after him and offers more security. Additionally, on the contrary to our scheme above, we only need a minimum amount of k out of n participants to reconstruct the secret. Our specification will be based on this scheme. 3. Overview and preliminaries In this section, we make some preparations for the protocol specification itself. 3.1. Scope In this document we describe the protocol specification for a Shamir Secret Sharing scheme on a finite field of size p > s and p > N, with p be prime number. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3.2. Notation We will use for public, non-secret, values UPPER CASE and for private, secret, values lower case. We write: "a", type: b, c, d "a" gives the name of the parameter. type: b be the type of the parameter a. c be the amount of this parameters. d be the mathematical definition set for a. Mathematical assignments: Let "a := b" be the assignment of the value of b to the variable a. Let "a mod b" be the modulus calculation of a with respect to b. Let "a != b" be that a is unequal to b. In our document "natural numbers" are defined as the set of all integers greater than zero. g[X] describes a polynomial with respect to X. SUM(a_i) gives the sum over a_i for all known i. SUM(i=a,b,c_i) gives the sum over all c_i for all a <= i <= b. PRODUCT(a,b,c_i) gives the product over all c_i for all a <= i <= b. The secret sharing protocol has three participating parties which we will call as follows: Secret Keeper (SK) knows the secret, does the initial setup and determines the secret shares. Share Holders (SH) receive the secret shares from the SK. Secret Reconstructor (SR) takes a particular number of secret shares from the SHs and reconstruct the secret. 4. Protocol outline We give a raw protocol overview. 0. Preparation: The parties negotiate an appropriate handshake and communication way for forwarding the secret shares between SK to the SHs and between the SHs to SR. [This is not part of that specifiation] => TODO: Do we need a more detailed definition of "appropriate"? 1. The SK knows the secret s. Additionally, given are the amount N of participating SHs and the threshold K for the minimum number of necessary shares for the reconstruction. [see sec. 5.1.] 2. The SK generate a random prime number p, with p > s AND p > N. [see sec. 5.3.] 3. The SK determines the secret polynomial coefficients a_j, 1 <= j <= K-1. With this, the secret keeping polynomial is given by g[X] := s + SUM(a_j*X^j). [see sec. 5.4.] 4. The SK determines the secret shares parts x_i, 1 <= i <= N. [see sec. 5.5.] 5. The SK computes the secret shares parts y_i := g[x_i]. [see sec. 5.5.] 6. The SK forward the secret shares to the SHs. Each SH_i MUST receive exactly one secret share pair (x_i,y_i). [see sec. 5.6.] 7. The SR receives K secret share pairs (x_h,y_h) from the SHs and p from the SK, 1 <= h <= K. [see sec. 5.7] 8. The SR compute the Lagrange basis polynomials l_h[X]. [see sec. 5.8.] 9. The SR reconstruct the original polynomial with g[x] = SUM(h=1, K, y_h*l_h[X] mod p). [see sec. 5.8.] 10. The SR computes the secret s = g[0]. [see sec. 5.8.] 5. Specification Now we will give more details to the raw outline above. 5.1. Given constants "s", type: int, exactly one, integer The given secret. "N", type: int, exactly one, natural number The number of participating SHs. It MUST to be N >= N_min. => TODO: Which value should N_min has? Default: N_min = 2? "K", type: int, exactly one, natural number The threshold of the minimum number of necessary shares for the reconstruction. It MUST to be K <= N. => TODO: Are more (size) information necessary? E.g. amount of bits/bytes? I think so. 5.2. Parties Secret Keeper (SK) It MUST exists exactly one SK. Share Holders (SH) It MUST exists exactly N SHs. Secret Reconstructor (SR) It SHOULD exists exactly one SR. [=> TODO: SHOULD since one is necessary but more could be used for checking the result. But I would prefere MUST.] => TODO: Which additional information do we need to know/to give about the parties? 5.3. Prime number Since we are using a secret sharing scheme on a finite field, we need a random prime number. "p", type: int, exactly one, prime number It MUST to be p > s AND p > N AND it MUST to be the secret s element of Z/pZ. => TODO: I'm not sure how exactly p should be handled. When and from where, is it given to whom? => TODO: Do we need to write anything about the necessary "random" characteristic? The "quality" of the randomly generation of the number? => TODO: Minimum size of p? Which value should p has, at least, caused by security reasons? => TODO: Are more (size) information necessary? E.g. amount of bits/bytes? I think so. 5.4. The secret keeping polynomial "a_j", type: int, K-1 values, Z/pZ "g[X]", type: polynomial with order K-1, exactly one, (Z/pZ)[X] The SK determines the final secret keeping polynomial, which is given by g[X] := s + SUM(a_j*X^j) and hence our secret for g[0] = s. Its random coefficients are a_j, 1 <= j <= K-1 which MUST be element of Z/pZ. => TODO: Which constraints exists for this a_j values? Size? Relative, pairwise, distance a_j - a_m between for all a_j,a_m with j != m? Is this relevant? References for this? => TODO: Are more (size) information necessary? E.g. amount of bits/bytes? I think so. 5.5. The secret shares "x_i", type: int, N values, Z/pZ "y_i", type: int, N values, Z/pZ "(x_i,y_i)", type: (int,int), N value pairs, Z/pZ -> Z/pZ The SK determines the random secret shares parts x_i, i <= N which MUST be element of Z/pZ and MUST be pairwise different from zero. With this x_i, SK computes the secret shares parts y_i := g[x_i] and hence the finally secret share pairs (x_i,y_i). => TODO: How should this x_i be generated? Distribution? E.g. the smallest, non negative, representatives? => TODO: Which constraints exists for this x_i values? Size? Relative, pairwise, distance x_i - x_m between for all x_i,x_m with i != m? Is this relevant? References for this? => TODO: Are more (size) information necessary? E.g. amount of bits/bytes? I think so. 5.6. Sending secret shares from SK to SHs The SK sends the secret share pairs to the SHs. Each SH_i MUST receive exactly one secret share pair (x_i,y_i). => TODO: How exactly has to look the data which has to be send and which size has it (bits/bytes) to be? => TODO: Which data has also to be send apart from (x_i,y_i)? => TODO: How should looks like a possible answer of the SHs for the SK to confirm the receipt? [Is this necessary, at all? I think so.] => TODO: I'm not sure how exactly p should be handled. When and from where, is it given to whom? => TODO: I need a helping hand for this specification section :) 5.7. SR receives secret shares from the SHs The SR MUST receive K secret share pairs from the SHs and p from the SK. The SR MUST receive exactly one secret share pair (x_,y_h), 1 <= h <= k, from each SH_h => TODO: How exactly has to look the data which has to be send as response to the SHs? What, which additionally data, has to be send? And which size has it (bits/bytes) to be? => TODO: I'm not sure how exactly p should be handled. When and from where, is it given to whom? => TODO: From where comes the information about N and K? (and p?) => TODO: Where has to be decided, from which K out of N SHs has this (x_h,y_h) to come from? And how (randomly)? And in which way has this to be comunicated to the given parties? !!! => TODO: I need a helping hand for this specification section :) 5.8. Reconstruction "l_h[x]", type: polynomial with order K-1, K, (Z/pZ)[X] The SR compute the Lagrange basis polynomials l_h[x] with the secret share pairs (x_h,y_h), 1 <= h <= K, which it received from the SHs. The SR MUST receive exactly K pairs from exactly K SHs. I MUST be exactly one secret share pair from each, of this K, SH. The Lagrange basis polynomials are given by l_h[X]:= PRODUCT(1 <= m <= K AND m != h, (X - x_m)/(x_h - x_m)) with 1 <= j <= K. This leads to our original secret keeping polynomial g[X] := SUM(h=1, K, y_h*l_h[x] mod p) and the given secret by s = g[0]. => TODO: From which K out of N SHs come this secret shares? => TODO: Are more (size) information necessary? E.g. amount of bits/bytes? I think so. 6. Security discussion => TODO: Write important points about the security aspects of this scheme. :) 7. References [1] https://www.cypherpunks.ca/~iang/pubs/privex-ccs14.pdf [maybe add also a reference here] [2] http://www.robgjansen.com/publications/privcount-ccs2016.pdf [3] https://github.com/privcount/privcount [4] Shamir A., "How to share a secret", Communications of the ACM. 22, 1979, S. 612–613. => TODO: References => TODO: Correct references for regular citation => TODO: Add missing references A. Lemma => TODO: Still to write. The Lemma (why this Shamir thing works :) proof ========== TODO: RESEARCH AND EXTENSION OF SPECIFICATION!!! => TODO: Investigate more some very interesting papers! :) => TODO: Multi-Secret Sharing Schemes!!! TODO: MISC: => TODO: Notation stuff checking => TODO: Check my English for language mistakes :) => TODO: I used: scheme, algorithm, protocol, ... what is the best word in what context? ========== -- ----------------------------------------------------------------------- Carolin Zöbelein / Nick: Samdney PGP: D4A7 35E8 D47F 801F 2CF6 2BA7 927A FD3C DE47 E13B -----------------------------------------------------------------------

4 7

User perception of the prop224 domain format
by Philipp Winter 27 Sep '17

27 Sep '17

We recently ran a survey on the usability of Tor and onion services [0]. I had a closer look at how our respondents perceive the prop224 domain format and wanted to share some early insights. The original survey question was: > The Tor Project is currently working on the next generation of onion > services. The new onion domain format will consist of 52 characters, > for example: > a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion > Do you expect this to change your browsing habits? 591 users answered this question. 95 (16%) selected that prop224 domains will change their habits while the remaining 496 (84%) selected that their habits won't be affected. Respondents who believe that their habits will change (16%) gave the following reasons: - Several users memorise a number of onion domains -- most prominently Facebook's onion domain and self-hosted domains. They write that memorising domains will no longer be possible, and they will look into bookmarking tools. Several users voiced concern about the confidentiality of their bookmarks, so they are looking into ways to encrypt them. - Similarly but less commonly, users voice concerns that communicating, typing, and writing down prop224 domains will no longer be feasible. - A small number of users write that it will be harder to recognise onion domains. Alarmingly, one user mentioned that the lack of a discernible prefix will make it hard to recognise genuine domains, suggesting that they rely on an onion domain's easy-to-spoof vanity prefix. - A user suggested to add spaces to prop224 domains to "make the address more visually appealing." Respondents who believe that their habits will *not* change (84%) gave the following reasons: - The majority of this crowd never bothered to memorise onion domains and uses bookmarks. A bunch of users store domains in text files and an even smaller bunch uses search engines to rediscover domains. In general, most people in this category treat onion domains as an opaque identifier. - Some users write that the additional inconvenience is likely worth the extra security and anonymity. - Some users mention Reddit as their primary way of discovering onion domains. Judging by the above, I believe that the new domain format is among the minor usability issues surrounding onion services. In fact, an easy-to-remember domain format ranks last among the six criteria whose importance we asked users about. On a five-point Likert scale ranging from "not at all important" to "very important," we got the following results: - 77% think that quality of content is at least somewhat important. - 70% think that a search engine (like Google) for onion services is at least somewhat important. - 66% think that diversity of content is at least somewhat important. - 62% think that page load time is at least somewhat important. - 43% think that having an onion service version of popular services such as Facebook is at least somewhat important. - 26% think that an easy-to-remember domain format is at least somewhat important. However, our survey data is likely biased towards a particularly young and educated crowd that's presumably less bothered by technological hurdles, which may be why they can afford to care more about content. [0] <https://blog.torproject.org/take-part-study-help-improve-onion-services> Cheers, Philipp

3 4

Tor 0.3.1 -> 0.3.2 coverage update
by Nick Mathewson 26 Sep '17

26 Sep '17

So, here's some good news about unit test coverage (as measured by 'make check') in 0.3.2: Our (line) test coverage rate is up, from 52.88% to 54.72%. But here is some bad news: The number of uncovered lines has still increased (from 30860 to 31608), even though covered lines have increased more rapidly. If you're interested in tracking down where we need coverage, I have used our "cov-diff" tool to generate a cleaned diff from the old coverage to the new coverage. You can download it (it's big!) from https://people.torproject.org/~nickm/volatile/coverage-diff.xz The format is: it is a diff between normalized gcov output files. To find new or modified un-covered lines, look for lines that begin with the regex /^\+ *\#/ ("starts with a plus, then some spaces, then a #"). Any lines like this are good candidates for additional testing IMO. peace, -- Nick

1 0

Does "ar: `u' modifier ignored since `D' is the default (see `U')" warning qualify as a bug?
by Patrick Durusau 25 Sep '17

25 Sep '17

Hello, Running Ubuntu 16.04, using: https://gitweb.torproject.org/tor.git/tag/?h=tor-0.3.2.1-alpha Following: https://lists.torproject.org/pipermail/tor-project/2017-September/001449.ht… and I get this warning 17 times from make: ar: `u' modifier ignored since `D' is the default (see `U') I traced this back to line 187 in Makefile.in ARFLAGS = cru Correcting to: ARFLAGS = cr src compiles sans the warnings. Is that a bug meriting a ticket? My primary strength is documentation and making mistakes in following it. ;-) Hope everyone is looking forward to a great weekend! Patrick -- Patrick Durusau patrick(a)durusau.net Technical Advisory Board, OASIS (TAB) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau

2 1

Anybody from Tor wants to participate at the pluggable transport meeting?
by vmon＠riseup.net 21 Sep '17

21 Sep '17

Hello Tor people, Dlshad (dothman(a)internews.org) from Internews has reached out to me to see if anybody from Tor is interested to participate in the next PT community meeting happening in Boston just after Tor-dev meeting. My understanding is that they'll book your ticket and arrange the accommodation for you. "I wanted to reach out to you and see if someone from Tor can join the Pluggable Transports community meeting which is going to be in Boston October 16-18. In this meeting, the community will discuss and go through the current draft of PT Spec https://www.pluggabletransports.info/spec/ and then release it. The rest of the meeting will be focusing on PT implementation." Cheers, vmon

1 0

Padding prop224 REND1 cells to blend them with legacy cells
by George Kadianakis 20 Sep '17

20 Sep '17

Hello Ian, (and other cryptographers on the list) here is a quick question which you might be able to answer super fast: Legacy RENDEZVOUS1 cells are bigger than the prop224 ones. The prop224 spec suggests we pad the new cells so that they look similar in size to the legacy ones. Here is how the legacy ones look like: RC Rendezvous cookie [20 octets] g^y Diffie-Hellman [128 octets] KH Handshake digest [20 octets] Here is how the prop224 ones look like: RENDEZVOUS_COOKIE [20 bytes] HANDSHAKE_INFO [64 bytes] The suggestion is to pad the prop224 cells to 168 bytes using random data. Would that work? My main question is whether the g^y part of the legacy cell has any distinguishers that could distinguish it from random data. It's encoded using OpenSSL's BN_bn2bin() and it's a 1024 bit DH public key. Are there any algebraic or openssl structure distinguishers we should be worrying about, or is random data sufficient to mask it out? Thanks!!! :)

2 2

Re: [tor-dev] Padding prop224 REND1 cells to blend them with legacy cells
by Ian Goldberg 20 Sep '17

20 Sep '17

Resending from a subscribed address. On Tue, Sep 19, 2017 at 05:44:46PM +0300, George Kadianakis wrote: > Hello Ian, (and other cryptographers on the list) > > here is a quick question which you might be able to answer super fast: > > Legacy RENDEZVOUS1 cells are bigger than the prop224 ones. The prop224 > spec suggests we pad the new cells so that they look similar in size to > the legacy ones. > > Here is how the legacy ones look like: > > RC Rendezvous cookie [20 octets] > g^y Diffie-Hellman [128 octets] > KH Handshake digest [20 octets] > > Here is how the prop224 ones look like: > > RENDEZVOUS_COOKIE [20 bytes] > HANDSHAKE_INFO [64 bytes] > > The suggestion is to pad the prop224 cells to 168 bytes using random data. > > Would that work? My main question is whether the g^y part of the legacy > cell has any distinguishers that could distinguish it from random data. > It's encoded using OpenSSL's BN_bn2bin() and it's a 1024 bit DH public > key. Are there any algebraic or openssl structure distinguishers we > should be worrying about, or is random data sufficient to mask it out? > > Thanks!!! :) Is your goal that someone who sees the *plaintext* of that cell won't be able to tell if it's a legacy RENDEZVOUS1 cell or a new one? If so, life is a bit complicated, since the g^y field will always be in the prime-order subgroup. (Note: I'm not actually 100% sure Tor uses a generator of the prime-order subgroup for g in this part of the spec. But it should have, and so hopefully did.) If HANDSHAKE_INFO || PADDING_64 (the latter being the first 64 bytes of the padding) is _not_ in the prime-order subgroup, the observer will be sure it's a prop224 cell. If it _is_, the observer can't tell. If that's undesirable, you could always insist that PADDING_64 be chosen such that HANDSHAKE_INFO || PADDING_64 _is_ in the prime-order subgroup. Raise it to the power of the prime order q to check; if the result is 1, you're good. You'll need to try on average (p-1)/q random values of PADDING_64 before you get a good one. (NOTE: *NOT* CONSTANT TIME.) If p = 2q+1, that's just 2, so not *terrible*, but 2 1024-bit modexps might still be annoying. If for some reason p is a DSA modululus or something bizarre like that, life is much more annoying. (I hope it's not.) This is all assuming p is of the form 2^1024 - (some number at most say 2^960), so that HANDSHAKE_INFO || PADDING_64 won't be larger than p itself, which would be another problem. To be sure, what are the g and p values used in this particular Diffie-Hellman?

2 2

Re: [tor-dev] tor-dev Digest, Vol 80, Issue 10
by flipchan 19 Sep '17

19 Sep '17

I emailed someone that runned an out of date version of tor yesterday and maybe it's more efficient to have an auto mailer to remind ppl to update On September 19, 2017 2:00:09 PM GMT+02:00, tor-dev-request(a)lists.torproject.org wrote: >Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > >You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of tor-dev digest..." > > >Today's Topics: > > 1. Re: Auto-senescence and/or CW penalty for a less outdated tor > network? (nusenu) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 18 Sep 2017 17:30:00 +0000 >From: nusenu <nusenu-lists(a)riseup.net> >To: tor-dev(a)lists.torproject.org >Subject: Re: [tor-dev] Auto-senescence and/or CW penalty for a less > outdated tor network? >Message-ID: <6aaa7727-7013-2ff8-3eb1-ac9b752b5981(a)riseup.net> >Content-Type: text/plain; charset="windows-1252" > >>> 1) Auto-senescence >>> ------------------- >> >> I think automatic timed shutdown can be unhelpful or dangerous: > >Yes it reduces the number of options once such a feature would be >implemented and deployed. > >> * what if we need it earlier due to a severe bug or mandatory >feature? > >This should not be an issue since that auto-shutdown only mandates an >upper limit but does not stop you from removing a relay before that >limit has been reached. > >> * what if it isn't needed, and the relay version is fine? > >Yes this can be an issue, but if you say "every relay that runs >versions >past its eol date" [1] is "not fine" then the auto-shutdown date can be >specified with a very high likelihood to a date that is past the eol >date because you have an estimate of how long you plan to support it >(3y >for LTS). > >I'm less concerned about auto-shutdown for tor clients since most tor >users might be using TBB with auto updates and it would help you having >to do things like prop266. > >[1] >https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… > >>> 2) consensus weight penalty for outdated relays >>> ----------------------------------------------- >> >> I can't see much point in this: if the relays are insecure, they >> should be eliminated. If not, they should be used. > >I'm happy with "insecure -> should be removed". >With "outdated" I meant "not running a recommended version" I'm not >sure >if that is the same as 'insecure'. > >A CW penalty would be a strong incentive for relay operators to keep >their relays up to date (to a recommended version). >This would likely reduce the number of relays running not-recommended >versions because currently the incentive is inverted (never >restart/update your tor instance - uptime!). >..but it would also affect testers running master. > > >>> 3) update tor dir auth code to reject old tor releases (not include >them >>> in consensus) >>> >------------------------------------------------------------------------- > >> In the past, we've excluded relay versions when they don't have a >> required feature. > >Does this step (excluding specific versions) require a code change or a >dir auth configuration change? (like it does for changing recommended >versions list) >If it does: Maybe it could be turned into a configurable option for dir >auths like recommended version. > >(3) will not stop old relays from contacting dir auths. > > >> We have a ticket to make a plan to kill off old client versions: >> https://trac.torproject.org/projects/tor/ticket/15940 >> But there's no equivalent ticket for relay versions. > > > >-- >https://mastodon.social/@nusenu >https://twitter.com/nusenu_ > >

1 0

Auto-senescence and/or CW penalty for a less outdated tor network?
by nusenu 18 Sep '17

18 Sep '17

Hi, tl;dr: ideas to reduce the cw fraction that outdated relays make up of the tor network This email can be somewhat summarized by these three polls: https://twitter.com/nusenu_/status/909356846900801536 https://twitter.com/nusenu_/status/909359701908971520 https://twitter.com/nusenu_/status/909361044988071936 This email was sparked by a recent thread on twitter. As of 2017-09-16 more than 27% CW fraction of the tor network (>2500 relays) run a version of tor that is not recommended by tor's directory authorities [2]. More than 8% CW fraction (>1100 relays) even run tor branches that reached end-of-life and are no longer maintained. So if we agree that 27% CW fraction is to much, we could aim at reducing that fraction within the tor network. Here are a few ideas. 1) Auto-senescence ------------------- Alfie John suggested [1]: > automatic shutdown after its version is too old as used in zcash (the tor snap from Chad Miller does auto-shutdown already today), Moritz replied: > Tor already has this mechanism in the form of recommended/required versions in consensus I looked into that [3] but this is about tor _protocols_ (not versions) and is probably better suitable for avoiding compatibility issues within the tor network as multiple protocols coexist but you can not use that to remove specific tor versions because many versions share the same protocol set [4]. [1] https://twitter.com/alfiedotwtf/status/906310842672603136 [2] https://consensus-health.torproject.org/#recommendedversions [3] https://gitweb.torproject.org/torspec.git/tree/proposals/264-subprotocol-ve… [4] https://gist.github.com/nusenu/1302a04b26dac8e2ef838117f5f3fd2b So back to Alfie's suggestion. If tor should shutdown when 'too old' we have to know what 'too old' is. To come up with a timespan for 'too old' I looked into 61 currently used tor versions that are no longer recommended by dirauths. I measured the time between release date (as mentioned in the changelog) and the last consensus where the given version was listed as a recommended relay tor version [5], but these graphs show the "recommended" lifespan of releases before the new support policy [6] with shorter release cycles for "regular" releases has been introduced. [5] https://twitter.com/nusenu_/status/909355193434853376 [6] https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… So instead of of using this historical data we could simply follow the support policy. regular release: Auto-shutdown 18 months (=9+grace period) after the branch became stable. LTS relase: Auto-shutdown 4 years (=3+grace period) after the branch became stable. Dates would be hardcoded and do not require relays to contact dirauths. So old relays will not but any load on dir auths and fallbackdirs everytime they start. Lets simulate these timespans for tor 0.2.4 and 0.2.5 (and lets assume they are LTS releases) - tor 0.2.4 relays - if they had such a logic - would shutdown on 2017-12-11 (eol date was 2017-08-01) - tor 0.2.5 relays whould shutdown on 2018-10-24 (eol date is 2018-05-01) (not mentioning 0.2.6/7 here) - tor 0.2.9 relays would shutdown on 2020-12-19 (eol date is 2020-01-01) You could add a torrc option to allow operators (and package maintainers) to opt-out of auto-shutdown. There is no doubt that any mechanism to disable old relays _automatically_ and by _default_ would shrink the tor network (compared to not having that), so having a good answer for "What is an acceptable CW fraction for outdated tor versions on the network?" would be important, but since the reasons for removing versions from the recommended list are very different the recommended datapoint might not be enough. 2) consensus weight penalty for outdated relays ----------------------------------------------- Instead of (or additionally to) telling relays to not upload descriptors (complete removal) you could _automatically_ reduce/cap their consensus weight on the dirauth side if they run - unsupported branches (harsher penalty) - run not-recommended tor releases over a long time (less harsh penalty) (The distinction between unsupported branches and not-recommended is currently not available as consensus information.) This approach makes the recommended version list a more critical consensus item and as you know this is not always managed ideally: - new releases not added to the list in a timely manner -> operators upgrading timely get warnings - old releases not removed timely or before deb.torproject.org provided new releases 3) update tor dir auth code to reject old tor releases (not include them in consensus) ------------------------------------------------------------------------- As soon as a tor directory operator updates to a new release the dirauth would no longer vote for specific tor versions (I guess this is the current mostly manual approach). Another important aspect is the practical reality in current package repositories, but I simply assume they will follow LTS releases and are fine with the 4 years (3+grace period) lifespan. regards, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

2 2

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 17 Sep '17

17 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

[release] CollecTor 1.3.0, metrics-lib 2.1.0, Onionoo 4.1-1.5.0
by iwakeh 15 Sep '17

15 Sep '17

Hi there! three new releases are available: https://dist.torproject.org/collector/1.3.0/ https://dist.torproject.org/metrics-lib/2.1.0/ https://dist.torproject.org/onionoo/4.1-1.5.0/ These releases upgrade all projects to use Java 8. A few issues and improvements come along and can be found in the change-logs [0], [1], [2]. Please direct comments and questions to the metrics-team mailing list [3]. Cheers, iwakeh [0] https://gitweb.torproject.org/collector.git/tree/CHANGELOG.md?h=collector-1… [1] https://gitweb.torproject.org/metrics-lib.git/tree/CHANGELOG.md?h=metrics-l… [2] https://gitweb.torproject.org/onionoo.git/tree/CHANGELOG.md?h=onionoo-4.1-1… [3] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

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

Proposal 282: Remove "Named" and "Unnamed" handling from consensus voting
by Nick Mathewson 12 Sep '17

12 Sep '17

Filename: 282-remove-named-from-consensus.txt Title: Remove "Named" and "Unnamed" handling from consensus voting Author: Nick Mathewson Created: 12-Sep-2017 Status: Open Target: 0.3.3.x 1. Summary Authorities no longer vote for the "Named" and "Unnamed" flags, and we have begun to remove the client code that supports them. (See proposal 235). The next logical step is to remove the special handling from these flags from the consensus voting algorithm. We specify this here. 2. Proposal We add a new consensus method, here represented as M, to be allocated when this proposal's implementation is merged. We specify that the Named and Unnamed flags are only handled specially when the negotiated consensus method is earlier than M. If the negotiated method is M or later, then the Named and Unnamed flags are handled as if any they were any other consensus flags.

1 0