tor-dev September 2017

tor-dev@lists.torproject.org

22 participants
18 discussions

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

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev September 2017