- tor-dev - lists.torproject.org

Release Candidate: TBB 3.6 + fteproxy 0.2.6
by Kevin P Dyer 13 Feb '14

13 Feb '14

Hi all, Please see [2] for a patch that integrates fteproxy into dcf's 3.6-beta branch [3] of the TBB. This integration targets version v0.2.6 of fteproxy [1]. asn/mikeperry - What do you need from me to merge this patch to master? -Kevin [1] https://github.com/kpdyer/fteproxy/releases [2] https://trac.torproject.org/projects/tor/ticket/10362#comment:11 [3] https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git

3 4

ScrambleSuit issue in old bridges
by George Kadianakis 12 Feb '14

12 Feb '14

(Forwarding this mail to tor-dev, since I accidentally sent it to tor-assistants) Hey Philipp, another thing we should think about is what should happen when ScrambleSuit is run in bridges that don't support server-side PT parameters. In the past this was not a problem, because ScrambleSuit would not run at all in those older versions of Tor. However, after we introduced the automatic generation of scramblesuit fallback passwords, scramblesuit will happily startup, generate a fallback password, and pass it to Tor. The problem is that Tor will simply ignore the fallback password (see parse_smethod_line() in tor-0.2.4.x), but still pass the scramblesuit bridge to BridgeDB. So if I'm not mistaken, BridgeDB might see some scramblesuit bridges without a password. Such bridges are pretty much useless, since clients can't connect to them. What should we do about this? One solution might involve scramblesuit somehow recognizing the version of Tor, and refusing to start if Tor doesn't support server-side bridge parameters.

1 0

A threshold signature-based proposal for a shared RNG
by Nicholas Hopper 11 Feb '14

11 Feb '14

A Threshold Signature-based Shared RNG 0. Overview This proposal is for a design of a shared RNG to address ticket #8244 - "The HSDirs for a hidden service should not be predictable indefinitely into the future," /without/ requiring byzantine agreement protocols at each RNG period. The basic idea of this proposal is to have directory authorities use a deterministic threshold signature scheme to sign Hash(time-period) in each consensus document. This is done simply by having each authority contribute a publicly-verifiable share of the signature during the voting process. As long as at least ceiling(n/2) authorities are honest, the signature can be re-constructed by each client. Since the signature is hard to compute if you don't control at least ceiling(n/2) authorities, its inclusion in the input to a hash function (e.g. for use in constructing the HS hash ring) will make the output of the hash function pseudorandom. (In the strong cryptographic sense that unless you can break the signature scheme, you can't distinguish the hash from a truly random string of the same length) 1. Notation and such This protocol can work over a group G, using a subgroup generated by an element B of prime order p. We'll use Curve25519 [Curve25519] for concreteness, but any group where the Computational Diffie-Hellman problem is difficult would do. We'll denote multiplication of scalars (e.g. mod p) by *, e.g. a*b; we'll denote multiplication of a group element P by scalar a by a.P. We will make use of Shamir threshold secret sharing, described, e.g. in Handbook of Applied Cryptography [HAC], over the integers mod p. For a subset S = {P_1,...,P_t} of size t, we'll denote the lagrange multipliers for S by m_1,...m_t (eg. if each P_i has share s_i of secret x, then m_1*s_1 + m_2*s_2 + ... + m_t*s_t = x.) We assume that each authority S_i has a publicly known verification key VK_i and signing key sk_i for a digital signature scheme (Sign, Verify). We model network communications as point-to-point with bounded delay and assume at most t-1 authorities are compromised. (Without these assumptions, the consensus voting protocol is also broken) We'll need a hash function H that can output elements of the subgroup generated by B with unknown discrete logarithms. For Curve25519, it should work to compute H(x) by computing SHA256(x), and mapping this 256-bit string to the curve as in the Curve25519 paper. A security proof would model this H as a random oracle. We'll need a distributed threshold key generation algorithm which works as follows: Input: Parties S_1,...,S_n Output: to all players: group public key P = x.B. player public key shares s_1.B, ..., s_n.B to each player P_i: secret key s_i) such that the secret keys s_i are (n,t) secret shares of the (unknown) secret key x. We discuss choices to implement this protocol in section [DKG] We will also require a noninteractive zero-knowledge "signature of knowledge" that can be bound to a message m, to prove that two points P, Q have a common discrete logarithm to bases B and R respectively. We denote this proof by SK { s : s.B = P && s.R = Q } (m) and discuss its implementation in section [SKDH]. 2. Overall Protocol description [CONSENSUS-RANDOM] The protocol requires that periodically the authorities run the distributed key generation procedure to produce the threshold public key P = s.B, and public key shares P_1 = s_1.B, ... , P_n = s_n.B. This can be done infrequently, since its only purpose is to limit key exposure. For the time period starting at time T, the authorities generate the shared random value as follows: Step 1. [Period Base] Each authority (and anyone else interested) generates the "time period base point" R in G, by computing R = H("tor-hs-rand-base-point " || period valid-after time) Step 2. [Signature Share] Each authority S_i uses its secret share s_i and signing key sk_i to generate its signature share SHARE_i as follows: SHARE_i = R || Q_i || PROOF_i || Sign_i(R || Q_i || PROOF_i) Q_i = s_i.R PROOF_i = SK { s_i : s_i.B == P_i && s_i.R == Q_i }(S_i || T) Each SHARE_i is appended by S_i to the network consensus document for time period T in a separate section. Step 3. [Validation] Tor clients locally validate SHARE_i from server S_i for time period T as follows: i. Verifythe signature using verification key vk_i. ii. Check that R = H("tor-hs-rand-base-point " || T). iii. Verify PROOF_i for points (P_i, Q_i) with bases (B,R) . SHARE_i is considered valid if and only if all three checks succeed. Step 4. [Aggregation] If at least t = ceiling(n/2) valid shares appear in the consensus, Tor clients locally compute the randomizer string RAND for time period T as follows: i. Let (S[j], Q[j]) for j = 1,...,t denote the identities (S_i) and signature shares (Q_i) associated with t valid SHARE_i values. ii. Compute the Lagrange multipliers m[j] for x points S[1]...S[t] iii. Compute RAND = m[1].Q[1] + m[2].Q[2] + ... + m[t].Q[t] Notice that RAND = m[1]*s[1].R + ... + m[t]*s[t].R = x.R If there are not enough valid shares, the protocol fails; this indicates that a majority of the directory authorities are faulty or compromised. If we wanted a fail-open solution, possibilities include hashing the list of valid SHARE values, or taking the hash of the previous consensus RAND value. [XXX - other options or opinions?] 3. Signature of knowledge scheme [SKDH] Given values (R,S), bases (P,Q), and exponent s such that R=s.P, S = s.Q, we use the "Fiat-Shamir Heuristic" with the proof of equality of discrete logarithms due to Chaum-Pedersen [CP92, Sec. 3.2] to generate SK { s : s.P == R && s.Q == S } (m) As follows: i. Choose random integer a in [0,p-1] ii. Compute: U = a.P V = a.Q c = Hash(U || V || m) z = a + s*c (mod p) iii. Output (U,V,z) The proof is verified by computing cc = Hash(U || V || m) and checking that z.P == U + cc.R z.Q == V + cc.S 4. Distributed Key Generation [DKG] We'll need a protocol satisfying the following specs: Input: Parties S_1,...,S_n Output: to all players: group public key P = x.B. player public key shares s_1.B, ..., s_n.B to each player P_i: secret key s_i such that the secret keys s_i are (n,t) secret shares of the (unknown) secret key x. There are several options for such a protocol, depending on what we want to assume about the network over which the authorities will run the protocol (Presumably, the Internet): - If we assume "weak synchrony" (messages are eventually delivered without unbounded delay), the protocol of Kate and Goldberg [KG09] can tolerate floor((n-1)/3) corruptions and still run to completion. - If we assume bounded delay but allow "rushing" adversaries and adaptive corruptions, the protocol of Garay et al [GKKZ11] can be used to realize the broadcast channel required for Pedersen's protocol [Ped91] while tolerating up to t-1 = floor(n/2) corruptions. - If we assume bounded delay and static corruptions, the protocol of Dolev and Strong [DS83] can be used to realize the broadcast channel required for Pedersen's protocol and tolerate up to t-1 corruptions. I'm not an expert on byzantine agreement protocols, so it is possible that there exist other, more easy to implement/manage options as well. 5. References [CP92] David Chaum, Torben Pryds Pedersen. "Wallet Databases with Observers", CRYPTO 92, pp 89-105. http://link.springer.com/chapter/10.1007/3-540-48071-4_7 [CURVE25519] Daniel J. Bernstein. "Curve25519: new Diffie-Hellman speed records", PKC 2006, pp 207-228. http://cr.yp.to/papers.html#curve25519 [DS83] D. Dolev and H. Strong. "Authenticated algorithms for Byzantine agreement", SIAM J. Computing 12(4):656-666, 1983. http://www.cse.huji.ac.il/~dolev/pubs/authenticated.pdf [GKKZ11] Juan Garay, Jonathan Katz, Ranjit Kumaresan, Hong-Sheng Zhou. "Adaptively Secure Broadcast, Revisited", PODC 11, pp 179-186. http://chess.cs.umd.edu/~jkatz/papers/asb-final.pdf [HAC] Alfred Manezes, Paul van Oorschot, Scott Vanstone. "Handbook of Applied Cryptography", CRC Press, 1996. http://cacr.uwaterloo.ca/hac/ [KG09] Aniket Kate, Ian Goldberg. "Distributed Key Generation for the Internet", 29th International Conference on Distributed Computing Systems, June 2009. https://cs.uwaterloo.ca/~iang/pubs/DKG.pdf [Ped91] Torben Pryds Pedersen. "Non-interactive and information-theoretic secure verifiable secret sharing," CRYPTO91. http://www.cs.huji.ac.il/~ns/Papers/pederson91.pdf -- ------------------------------------------------------------------------ Nicholas Hopper Associate Professor, Computer Science & Engineering, University of Minnesota Visiting Research Director, The Tor Project ------------------------------------------------------------------------

3 7

Looking up bridges in Globe et al. by fingerprint
by Karsten Loesing 11 Feb '14

11 Feb '14

Hi bridge address distribution people, hi bridge status website developers, hi bridge operators, here's a problem that recently came up when Christian and I discussed making Globe a JavaScript-free website. The current Globe uses client-side JavaScript to detect if the user entered a 40-character hex fingerprint. In that case, it runs the input through SHA-1 and sends only the digest to the Onionoo service. That's why Onionoo supports four cases and does not support a fifth case (number 3 below): 1. original relay fingerprint: return the matching relay, because it might have been a different client than Globe that sent the request and did not run the fingerprint through SHA-1; 2. SHA-1 of relay fingerprint: return the matching relay, too, because this could have been Globe running the original relay fingerprint through SHA-1; 3. original bridge fingerprint: don't return anything, because Onionoo should not see original bridge fingerprints at all; 4. SHA-1 of bridge fingerprint: return the matching bridge, because not all clients are like Globe and might not run fingerprints through SHA-1; and 5. SHA-1 of SHA-1 of bridge fingerprint: return the matching bridge that the user was looking for when they put in the SHA-1 fingerprint which was then converted to the SHA-1 of the SHA-1. That's what the current Globe can do, because it uses JavaScript on the client side. But the new server-side Globe cannot do that! And I don't have a good solution yet. Here are some ideas, each of them having pros (-) and cons (+): 1. Globe runs full fingerprints through SHA-1 on the server. - The Globe server learns a lot of bridge fingerprints, which makes it a juicy target, because bridge fingerprints can (in the future?) be used to fetch bridge descriptors containing bridge addresses. + This variant is really easy to implement. 2. Globe does not run full fingerprints through SHA-1 on the server and instead forwards everything to Onionoo. - Not only the Globe server, but also the Onionoo server learns bridge fingerprints. + We teach users that they shouldn't copy their original bridge fingerprint into the Globe search window. For example, we could tell them the single line of Python they need to run their fingerprint through SHA-1. While they might have "spoiled" their first bridge, they'll know for their other bridges. - Nobody will understand the above. 3. Tor prints out the SHA-1 fingerprint to its logs or to a hashed-fingerprint file. + Bridge users who know to read the fingerprint file can as well read the hashed-fingerprint file or the logs. We could even add a link "How do I search for my bridge" to the Globe page and explain to look out for that file or read the logs. - Only very few people will find that file or click the link. We'll have to do either 1 or 2 in addition to 3. 4. Sanitized bridge descriptors contain original fingerprints. + It will be a lot easier to search for bridges if it works the same way as searching for relays. + The sanitizing process will be easier. - We lose the option to enable bridge clients to update their bridge descriptors by sending the bridge fingerprint to the bridge authority. - This is going to keep me busy for a while for updating the various metrics code that expects SHA-1 fingerprints rather than original fingerprints. I can do that though. What do you think? All the best, Karsten

3 5

obfsproxy & openvpn
by George Kadianakis 10 Feb '14

10 Feb '14

Hey Jurre, till we fix #9221 (the issue of obfsproxy not having a SOCKS5 listener), you might be able to work around this problem by doing what kheops did here: https://github.com/kheops2713/telecomix-openvpn/commit/83984d822290f3445adf… Basically he is using the external mode of obfsproxy, where he makes the client forward traffic to a specific IP/port instead of starting up a SOCKS listener. Might work...

2 1

Weather Rewrite Update
by Abhiram Chintangal 07 Feb '14

07 Feb '14

Hello Guys, I have made some small changes to the existing dajngo app, It would be great if you guys can provide some feedback. Since we might have different settings for testing and production and so on , I made a separate module for it [1]. For now, I check for the debug flag in the updaters module and disable email sending. Here is a link to the new commit [2] Thanks! [1] http://www.rdegges.com/the-perfect-django-settings-file/ [2] https://github.com/achintangal/weather/commit/68035eeea9d26c7f64efd9dbe5484… -- Abhiram Chintangal

1 0

Your 'Relay Web Status Panel' GSoC idea (was: r26589: {website} Adding 'Relay Web Status Panel' Adding a project I'm interes (website/trunk/getinvolved/en))
by Karsten Loesing 07 Feb '14

07 Feb '14

Hi Damian, this sounds like a fun project and a great GSoC project idea! Some quick feedback: Have you considered suggesting this relay web status panel for a possible Torouter? I could imagine making this the primary interface for a little Torouter box, so that people don't have to ssh into it or install a desktop application to connect to it. Which brings up two my questions: why not make this a "relay web status and *control* panel"? Are the security risks really that much higher compared to using arm? And if you distrust the web server part of this design, how do you prevent an attacker from breaking into the web server and abusing the controller connection to reconfigure the relay? And question number two: why not make this a "relay and *client* web status and control panel"? In the Torouter case, people might want to use their tor only as a client to route all their connections through tor. Think of a little box that provides wifi access to nearby strangers but tunnels everything through the local tor client to avoid legal trouble. Or, if strangers need anonymity, the guy running the box could configure it as (private) bridge and mention the address on its local website for strangers to use with their own tor client. I'm not at all suggesting to include all this in the GSoC project. But maybe these ideas could be mentioned or kept in mind? Looking forward to seeing this happen! All the best, Karsten On 05/02/14 18:01, Damian Johnson wrote: > Author: atagar > Date: 2014-02-05 17:01:31 +0000 (Wed, 05 Feb 2014) > New Revision: 26589 > > Modified: > website/trunk/getinvolved/en/volunteer.wml > Log: > Adding 'Relay Web Status Panel' > > Adding a project I'm interested in mentoring this summer. > > > > Modified: website/trunk/getinvolved/en/volunteer.wml > =================================================================== > --- website/trunk/getinvolved/en/volunteer.wml 2014-02-05 03:18:48 UTC (rev 26588) > +++ website/trunk/getinvolved/en/volunteer.wml 2014-02-05 17:01:31 UTC (rev 26589) > @@ -629,6 +629,7 @@ > > Project Ideas: > <a href="#txtorcon-stemIntegration">Txtorcon/Stem Integration</a> > + <a href="#relayWebPanel">Relay Web Status Panel </a> > > > <a id="project-txtorcon"></a> > @@ -917,6 +918,53 @@ > bonus points if it's Twisted. > </li> > > + <a id="relayWebPanel"></a> > + <li> > + Relay Web Status Panel > + > + Effort Level: Medium > + > + Skill Level: Medium > + > + Likely Mentors: Damian (atagar) > + > + Relay operators presently have a couple options for monitoring the status > + of their relay: <a > + href="https://www.torproject.org/getinvolved/volunteer.html.en#project-vidalia">Vidalia</a> > + which is a gui and <a href="https://www.atagar.com/arm/">arm</a> which uses > + curses. This project would be to make a new kind of monitor specifically > + for relay operators that provides a status dashboard site on localhost. > + > + > + The interface will likely <a > + href="https://www.atagar.com/arm/screenshots.php">borrow heavily from > + arm</a>, except of course in areas where we can improve upon it. Two > + important design constraints is that a localhost controller provides a > + bigger attack surface than guis or curses, so we should be a little more > + wary of what it does. This should be a read-only controller (ie, you can't > + *do* anything to the relay) and by default not surface any sensitive > + information (such as arm's connection panel). > + > + > + This project will likely include two parts: an AJAX site and a localhost > + daemon to fulfill those requests. <a > + href="https://stem.torproject.org/">Stem</a> is the backend of arm, and can > + be used to get everything you see in arm's interface (making it a natural > + choice for the daemon). That said, this project might entail some Stem > + improvements if we run across any gaps. > + > + > + Applicants should be familiar with Python, JavaScript, and learn about > + <a href="https://stem.torproject.org/">Stem</a>. As part of your > + application for this project please make both mockups of the interface and > + a proof of concept demo application using JS to surface something with > + Stem. <a > + href="https://trac.torproject.org/projects/tor/wiki/doc/stem/bugs">Involvement > + with Stem development</a> during the application process is also a big > + plus. > + > + </li> > + > <a id="httpsImpersonation"></a> > <li> > HTTPS Server Impersonation > > _______________________________________________ > tor-commits mailing list > tor-commits(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits >

3 2

[PATCH] Remove the trailing slash.
by Nikita Karetnikov 07 Feb '14

07 Feb '14

If you apply the attached patch atop of this one [1], you should be able to see the following. $ dist/build/runtests/runtests Cases: 21 Tried: 21 Errors: 0 Failures: 0 (The tests only check encoders/decoders, so you don’t need to have networking enabled.) Is there anything else I can do? [1] https://trac.torproject.org/projects/tor/attachment/ticket/9419/tordnsel.ca…

1 0

Re: [tor-dev] Help hacking Mumble
by Matt 07 Feb '14

07 Feb '14

On Thu, 30 Jan 2014 22:01:18 +0000 Matt <matt(a)pagan.io> wrote: Here is one of the Mumble developers' take on the issue: > I don't know where @zanethomas's post went, but I just want to clarify > what needs to be done here, and what's wrong. > > By default, Qt's proxy support can route hostname resolution through > the proxy if a hostname is used when creating the socket. > > However, in Mumble, we use QHostAddress to resolve addresses ahead of > time in a lot of places (for example, the server list), which causes > the DNS requests to not go through the proxy. > > We need some kind of abstraction on top of QHostAddress that allows us > to route the hostname lookups via the user's selected proxy. That, or > we need to upstream a Qt patch that allows QHostAddress to resolve > through the application's QNetworkProxy. > > ...Something along those lines. Source: https://github.com/mumble-voip/mumble/issues/1033

2 1

Web Relay Status Dashboard Brainstorming
by Damian Johnson 06 Feb '14

06 Feb '14

Hi Karsten, thanks for the feedback! Updating the subject so it's clearer to others that this is a brainstorming thread for a web relay status dashboard. For people just jumping in on this thread, we're discussing a possible GSoC project for a new controller interface... https://www.torproject.org/getinvolved/volunteer.html.en#relayWebPanel > this sounds like a fun project and a great GSoC project idea! > > Some quick feedback: Have you considered suggesting this relay web status > panel for a possible Torouter? I could imagine making this the primary > interface for a little Torouter box, so that people don't have to ssh into > it or install a desktop application to connect to it. Great point. Added a note regarding it... https://lists.torproject.org/pipermail/tor-commits/2014-February/068398.html > Which brings up two my questions: why not make this a "relay web status and > *control* panel"? Are the security risks really that much higher compared > to using arm? And if you distrust the web server part of this design, how > do you prevent an attacker from breaking into the web server and abusing the > controller connection to reconfigure the relay? Certainly could. I'd like for the daemon that services the AJAX requests to be customizable via a local config. By default it would only allow read-only requests for non-sensitive data (ie, not connections). However, the operator could easily allow those to make the panel more capable. The reason that I'm more wary of a web panel than a local application like arm is... * Network facing applications like web browsers and mail clients tend to be a more expose attack surface. To do something malicious with arm an attacker would need local filesystem access for the authentication cookie or control socket (at which point they could just connect to the control port directly - arm isn't adding to the risk). With a web panel, however, all they need to do is trick the web browser into issuing AJAX requests to localhost. * The daemon that services AJAX requests is essentially providing a method to bypass Tor's control port authentication. The daemon authenticates to Tor, but the daemon's users don't necessarily have access to the filesystem. > And question number two: why not make this a "relay and *client* web status > and control panel"? In the Torouter case, people might want to use their > tor only as a client to route all their connections through tor. Think of a > little box that provides wifi access to nearby strangers but tunnels > everything through the local tor client to avoid legal trouble. Or, if > strangers need anonymity, the guy running the box could configure it as > (private) bridge and mention the address on its local website for strangers > to use with their own tor client. > > I'm not at all suggesting to include all this in the GSoC project. But > maybe these ideas could be mentioned or kept in mind? Certainly could. If this project really takes off then I'd love to see it expand to cover additional use cases. I'm just starting with relays to give the project an initial scope. > Looking forward to seeing this happen! Me too! I hope we get great applicants for this and the txtorcon/stem integration projects. Cheers! -Damian

1 0