- tor-dev - lists.torproject.org

globe compass integration
by Christian 05 Mar '14

05 Mar '14

Hi, in the last couple of days I thought about a topic for a gsoc application. After getting ideas from Karsten and Sathya, I started making a rough roadmap of things that I want to do for globe, in the next couple of months (and maybe use it as a idea for a gsoc topic). - add new onionoo features to globe - add compass functionality + open compass tickets to globe - improve/add help documentation The central point would be to add compass functionality to globe. This has the advantage that the user can use the same application to search for relay/bridge details and do queries with grouped results. This could be accomplished by changing the UI and modify advanced search filters, add options for grouping and grouped search results. Another suggestion was to add a group detail page that displays aggregated data for multiple details. Currently compass pulls all onionoo relay details and queries them locally. Karsten suggested that globe could use the same method and load the onionoo data every hour or so and do the currently supported search and compass functionality on it. The idea is that globe could store the dump in a db (e.g. mongodb) and use its features for searching, grouping and aggregating data. This would be a major rewrite away from calling the Onionoo-API, to querying the locally available dump. I would like to know, if you think that integrating Compass into globe would be a good idea? Do you think that the compass integration would be a reasonable project for the gsoc? Do you have other ideas on how to improve globe? Thanks, Christian

4 3

Tor HS DHT Research
by Gareth Owen 05 Mar '14

05 Mar '14

Dear all Sorry if this is the wrong list (please tell me if it is). I'm undertaking research into the tor HS DHT and have a couple of questions. I know at present, a node must be on for 25 hours to participate in the DHT; however, periodically I wish to make small code changes to Tor and restart the node (aka fairly instantly/within minutes) but this causes me to lose the HSDir flag. So my questions are: 1) Is there anyway to restart Tor without losing the HSDir flag? 2) Is uptime self reporting - e.g. is a node's self reported uptime trusted or is it obtained elsewhere - I couldn't find the answer in the code. I guess what I'm getting at, is can I fake the uptime to get the HSDir flag? Best Gareth --- Dr Gareth Owen School of Computing University of Portsmouth

2 2

Coordination of censorship analysis tool
by sarnicki＠student.agh.edu.pl 05 Mar '14

05 Mar '14

Hi everyone, could you provide some information about your progress on the project? I am interested in developing the tool, but I don't want to duplicate your work. Thanks, Piotr

2 2

[RELEASE] Torsocks 2.0.0-rc4
by David Goulet 04 Mar '14

04 Mar '14

Hi everyone! After a big code review from Nick and help from a lot of people contributing and testing, this is the release candidate 4 for the new torsocks. Hopefully this is the last stretched before pushing this effort upstream but for that we need help with code/documentation review (again) and of course more and more testing! Multiple Signed-off on the code would be great so please go at it, ask questions, contribute! and let's make this new Torsocks awesomer! :) Some pointers on critical part of the code. --> src/lib/connect.c and close.c --> src/lib/getaddrinfo.c and gethostbyname.c --> src/lib/torsocks.c Also see the configuration file that has changed. --> doc/torsocks.conf If you are on OS X or/and BSD, please help make it work on those platforms. It's quite easy to break compatibility thus help make sure we didn't break it up :). https://github.com/dgoulet/torsocks.git Tarball: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc4.tar.gz Big thanks to all! David

5 7

(no subject)
by Samual Carman 04 Mar '14

04 Mar '14

-- hello i have some questioner regarding helping the development of tor contact me off list if possible thank yuo the wyer

1 0

Search Engine for Hidden services
by Prakash kumar 03 Mar '14

03 Mar '14

Sir I am Prakash kumar from G. B. Pant Engineering College, Delhi, India.I am a 2nd year computer science and engineering student. I want to work on the idea "search engine for hidden services". I have a basic knowledge of how search engines work. I want to know which language we will use for this project. And also what is the next step from here? Please guide me. github: github.com/prakash09 facebook:https://www.facebook.com/prakashkumar09 Thank you Regards, Prakash Kumar

1 0

IRC meeting on Fri, Mar 7, 17:00 UTC to discuss TIMB's next external milestone
by Karsten Loesing 03 Mar '14

03 Mar '14

Hi everyone, we're going to have an IRC meeting to discuss next steps for the Tor Instant Messaging Bundle (TIMB): Friday, March 7, at 17:00 UTC in #tor-dev on OFTC. http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140307T17 The main topic will be the upcoming external milestone on March 31, 2014 and what we hope to have achieved by then. We'll also talk about (ab-)using Trac as project management system for this project. If people want to read up on what this is all about, here's the current wiki page for this project: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorO/TIMB Talk to you on Friday! Volunteers welcome! All the best, Karsten

1 0

Proposal 228: Cross-certifying identity keys with onion keys
by Nick Mathewson 03 Mar '14

03 Mar '14

Here's a proposal that's been kicking around on my laptop for a while. I cleaned it up to use the revised certificate format from the revised proposal 220. My math and crypto claims might be incorrect here; I'm sure hoping somebody will tell me if they are. Filename: 228-cross-certification-onionkeys.txt Title: Cross-certifying identity keys with onion keys Author: Nick Mathewson Created: 25 February 2014 Status: Open 0. Abstract In current Tor router descriptor designs, routers prove ownership of an identity key (by signing the router descriptors), but not of their onion keys. This document describes a method for them to do so. 1. Introduction. Signing router descriptors with identity keys prevents attackers from impersonating a server and advertising their own onion keys and IP addresses. That's good. But there's nothing in Tor right now that effectively stops you (an attacker) from listing somebody else's public onion key in your descriptor. If you do, you can't actually recover any keys negotiated using that key, and you can't MITM circuits made with that key (since you don't have the private key). You _could_ do something weird in the TAP protocol where you . Nonetheless, it's probably undesirable that this is possible at all. Just because it isn't obvious today how to exploit this doesn't mean it will never be possible. 2. Cross-certifying identities with onion keys 2.1. What to certify Once proposal 220 is implemented, we'll sign our Ed25519 identity key as described in proposal 220. Since the Ed25519 identity key certifies the RSA key, there's no strict need to certify both separately. On the other hand, this proposal may be implemented before proposal 220. If it is, we'll need a way for it to certify the RSA1024 key too. 2.2. TAP onion keys We add to each router descriptor a new element, "onion-key-crosscert", containing a RSA signature of: A SHA1 hash of the identity key [20 bytes] The Ed25519 identity key, if any [32 bytes] If there is no ed25519 identity key, or if in some future version there is no RSA identity key, the corresponding field must be zero-filled. Parties verifying this signature MUST allow additional data beyond the 52 bytes listed above. 2.3. ntor onion keys Here, we need to convert the ntor key to an ed25519 key for signing. See the appendix A for how to do that. We'll also need to transmit a sign bit. We can add an element "ntor-onion-key-crosscert", containing an Ed25519 certificate in the format from proposal 220 section 2.1, with a sign indicator to indicate which ed25519 public key to use to check the key: "ntor-onion-key-crosscert" SP SIGNBIT SP CERT NL SIGNBIT = "0" / "1" Note that this cert format has 32 bytes of of redundant data, since it includes the identity key an extra time. That seems okay to me. The TYPE field in this certificate should be set to [0A] - ntor onion key cross-certifying ntor identity key 3. Authority behavior Authorities should reject any router descriptor with an invalid onion-key-crosscert element or ntor-onion-key-crosscert element. Both elements should be required on any cert containing an ed25519 identity key. See section 3.1 of proposal 220 for rules requiring routers to eventually have ed25519 keys. 4. Performance impact Routers do not generate new descriptors frequently enough for them to need to Checking an extra ed25519 signature when parsing a descriptor is very cheap, since we can use batch signature checking. The point decompression algorithm will require us to calculate 1/(u+1), which costs as much as an exponentiation in GF(2^255-19). Checking an RSA1024 signature is also cheap, since we use small public exponents. Adding an extra RSA signature and an extra ed25519 signature to each descriptor will make each descriptor, after compression, about 128+100 bytes longer. (Compressed base64-encoded random bytes are about as long as the original random bytes.) Most clients don't download raw descriptors, though, so it shouldn't matter too much. A. Converting a curve25519 public key to an ed25519 public key Given a curve25519 x-coordinate (u), we can get the y coordinate of the ed25519 key using y = (u-1)/(u+1) and then we can apply the usual ed25519 point decomporession algorithm to find the x coordinate of the ed25519 point to check signatures with. Note that we need the sign of the X coordinate to do this operation; otherwise, we'll have two possible X coordinates that might have correspond to the key. Therefore, we need the 'sign' of the X coordinate, as used by the ed25519 key expansion algorithm. To get the sign, the easiest way is to take the same private key, feed it to the ed25519 public key generation algorithm, and see what the sign is. B. Security notes It would be very bad for security if we provided a diffie-hellman oracle for our curve25519 ntor keys. Fortunately, we don't, since nobody else can influence the certificate contents.

4 4

Weekly Tor dev meeting: Wednesday March 5, 20:00 UTC
by Nick Mathewson 03 Mar '14

03 Mar '14

Hi, all! This is another developer's meeting for working on the program "tor". (This won't cover all the other programs developed under the Tor umbrella.) Unlike last week, we're going to try doing the weekly meeting on Wednesday, so it can go right after the TBB meeting. Also, I'm going to say the date and time again in my message body, so that people who skim over the subject line can find it: Wednesday March 5, 20:00 UTC. (That's 3pm EST and 12:00 noon PST) As before, we'll do it on the #tor-dev IRC channel, unless the meeting turns out to be too disruptive for the rest of the channel or vice versa. peace, -- Nick

1 0

HOWTO use Lantern as a pluggable transport
by David Fifield 03 Mar '14

03 Mar '14

I met today with some developers of Lantern (https://getlantern.org/, https://github.com/getlantern/lantern) Lantern acts as an HTTP proxy and proxies your traffic through trusted friends. We found that we had the pieces necessary to make Lantern a pluggable transport of Tor; that is, use Lantern as a transport for Tor traffic where Tor is blocked but Lantern is not. Here's what we did to make it work. Lantern is an HTTP proxy. As luck would have it, I have lately been working on a transport that encodes data in HTTP requests (https://lists.torproject.org/pipermail/tor-dev/2014-January/006159.html) meek was designed for a completely different purpose--tunneling traffic through App Engine--but it turned out to be almost perfect for the Lantern case, too. The only thing it was missing was support for an upstream HTTP proxy. We used the attached patch to add proxy support and hardcode Lantern's proxy port of 8787. meek normally connects to App Engine, and uses a TLS trick to make it look like it is going to www.google.com. The meek-client program connects App Engine, and then App Engine forwards traffic to the bridge. The configuration looks like this: ClientTransportPlugin meek exec meek-client --url=https://meek-reflect.appspot.com/ --front=www.google.com With Lantern it's a bit different. We don't need to do the TLS fronting trick because we use Lantern as an opaque HTTP-carrying transport. Instead of going through App Engine, we tell meek-client to make requests directly to the Tor bridge (where "directly" means "directly through the Lantern proxy"). ClientTransportPlugin meek exec meek-client --url=http://tor1.bamsoftware.com:7002/ And that's all. We downloaded one of the experimental meek bundles from https://people.torproject.org/~dcf/pt-bundle/3.5.2.1-meek-1/, copied in the patched meek-client binary, and made the above change to the ClientTransportPlugin line in torrc-defaults. With Lantern already running and configured on the same machine, we started tor and it bootstrapped. I'll take the proxy patch and modify it so that the proxy address is not hardcoded, so that you can configure it from the command line. It could also be useful for users who need pluggable transports but are stuck behind an HTTP proxy. Special thanks to Ox from Lantern who pair-programmed this with me. David Fifield

1 1