- tor-dev - lists.torproject.org

Re: [tor-dev] Stegotorus - DELETE_METHOD
by vmon＠riseup.net 24 Mar '14

24 Mar '14

Hey Noah, I somehow lost your email and can't find it. But at first look it seemed to me that autoreconf(and configure) is not defining the DELETE_METHOD in config.h while it supposed to do so by virtue of "configure.ac:85:AX_CXX_DELETE_METHOD". Did you run autoreconf before going ahead with configure? FYI, this is how the bundler maker, makes stegotorus on a (relatively) clean debian x86_64 vm: git clone "$(STEGOTORUS_HOME)" "$(STEGOTORUS_WORK)" cd "$(STEGOTORUS_WORK)" && git checkout tor-improve #&& git checkout --detach "$(STEGOTORUS_TAG)" cd "$(STEGOTORUS_WORK)" && autoreconf cd "$(STEGOTORUS_WORK)" && ./configure PKG_CONFIG_PATH=`pwd`&& make For me after I run the autoreconf and configure, I'll have the following line in config.h: #define DELETE_METHOD = delete Could you please verify that and if not re-run the autoreconf, you might also want to share your automake and gcc version with me. You also might want to send me config.log for further investigation. Wish you all the best with your stegotorus adventure, vmon

1 0

Re: [tor-dev] Stegotorus - lisboost problem
by vmon＠riseup.net 23 Mar '14

23 Mar '14

Hey Noah, > The configure file cant seem to digest libboost (on ubuntu). i > installed 1.53-all-dev in /usr/lib/x86_64-linux-gnu/ and then took The problem is that not all distribution come with libboost.pc file (ubuntu/debian come with individual pc file for each component of boost but not one pc file for the whole boost library). I have left a libboost.pc file in the root directory of Stegotorus. Just copy it into /usr/lib/pkgconfig or where ever your other package config (.pc) files reside. We should resolve this problem more fundamentally if your application goes through. Thanks for your efforts and let me know if you managed to pass this barrier. Best of luck, vmon Noah Rahman <selimthegrim(a)gmail.com> writes: > The configure file cant seem to digest libboost (on ubuntu). i > installed 1.53-all-dev in /usr/lib/x86_64-linux-gnu/ and then took > that out and installed 1.54-all-dev in usr/lib. Even though I set the > libboost_LIBS variable properly. > > On Fri, Mar 21, 2014 at 3:13 PM, <vmon(a)torproject.org> wrote: > > > Noah Rahman <selimthegrim(a)gmail.com> writes: > > It says you'll have to enable modifications > > > Just did! I'll try to update the tickets sometime this weekend. >

1 0

GSoC 2014 : Rewrite Tor Weather
by Sreenatha Bhatlapenumarthi 22 Mar '14

22 Mar '14

Hi there! I am Sreenatha(lucyd). I am interested in working on Tor Weather this summer as a part of GSoC 2014. I helped Damian migrate weather to stem(#8264) last summer and have been following the work on it's rewrite. I made an attempt to further this by writing a couple of python scripts. 1. Relay Search using Onionoo : A python script[0] that uses onionoo's search functionality to find relays with specific fingerprint/nickname/IP address. For now, I've used a global variable to store the search results for better performance in case of a repeated query. Once the database structure for the new weather is confirmed, I'll modify it accordingly. Feedback on this is much appreciated. 2. Patch for #9889 : I've also submitted a patch[1] for #9889 that checks if a given relay qualifies for a t-shirt. I'd really appreciate if you could take a look at my work and suggest possible improvements or provide some advice regarding the project in general. Cheers, Sreenatha [0] - https://github.com/lucyd/weather-rewrite/blob/master/search_relay.py [1] - https://trac.torproject.org/projects/tor/ticket/9889#comment:3

2 3

Fwd: About using source code
by saurav dahal 21 Mar '14

21 Mar '14

Can anybody please tell me how to use the original source code of tor by modifying and implementing on the TOR network? For example: I want to log how many circuits have been made through my OR. Thanks, Saurav

3 5

Tor integration into CACHeCoin
by kalgecin 21 Mar '14

21 Mar '14

Hey guys, I'm looking into integrating TOR network into CACHeCoin. The idea is, by default, the coin should connect through the tor network, with the option of disabling it and connecting normally. This will help boost some anonymity within the coin and help the TOR network by keeping up the nodes :-) The idea is, if the person activated connection through tor (which is already by default) he'll be able to receive stake. If he disables, No stake will be generated. Unfortunately i don't have much free time to dig into the tor code, but will be happy to receive the pull request on github https://github.com/kalgecin/CACHeCoin/ Please let me know what you think -- Kalgecin http://code.google.com/p/kalgecin *https://github.com/kalgecin <https://github.com/kalgecin>* https://plus.google.com/u/0/104834274682757290524<https://plus.google.com/u/0/104834274682757290524/posts> https://twitter.com/kalgecin

3 3

Panopticlick summer project
by Gunes Acar 21 Mar '14

21 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear All, My name is Gunes Acar, a 2nd year PhD student at Computer Security and Industrial Cryptography (COSIC) group of University of Leuven. I work with Prof. Claudia Diaz and study online tracking and browser fingerprinting. I'd like to work on "Panopticlick" (https://www.torproject.org/getinvolved/volunteer.html.en#panopticlick) summer project and other fingerprinting related issues which I tried to outline below: 1) Collaborate with Peter@EFF to port/open-source Panopticlick: https://trac.torproject.org/projects/tor/ticket/6119#comment:4 a) implement necessary modifications - e.g. we won't be having cookies or real IP addresses to match returning visitors. b) consider security implications of storing fingerprints (e.g. what happens if someone gets access to fingerprint database?) 2) Add machine-readability support outlined in Tor Automation proposals: https://people.torproject.org/~boklm/automation/tor-automation-proposals.ht… a) which one(s) should we implement? JSON, YAML, XML? 3) Survey the literature for fingerprinting attacks published since Panopticlick. Implement those that may apply to TBB: a) Canvas & WebGL fingerprinting (Mowery et al.) - make sure the patch at #6253 works b) JS engine fingerprinting (Mulazzani et al.) c) CSS & rendering engine fingerprinting, (Unger et al.) ... 4) Check with realworld fingerprinting scripts to see if they collect anything that is not considered before. Check if TBB's FP countermeasures work against them. (We can use data from FPDetective study to find sites with fingerprinting scripts) 5) Backport new "attacks" found in 3 & 4 to EFF's Panopticlick in case they consider an update. 6) Convert fixed FP-related bugs into regression tests. https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting… 7) Build test cases to check the severity of fingerprinting related open tickets, e.g.: https://trac.torproject.org/projects/tor/ticket/8770 https://trac.torproject.org/projects/tor/ticket/10299 8) Work on potential fingerprinting bugs that ESR31 may bring. 9) ESR transitions seem to create a lot of FP-related issues that need to be checked manually (e.g. #9608). Consider developing a tool that iterates over the host objects of two browsers to compare them automatically (e.g. to pinpoint new objects, new methods, updated default values, etc.). Similar to "diff tool" mentioned here: https://people.torproject.org/~boklm/automation/tor-automation-proposals.ht… 10) Evaluate the font-limits of TBB by checking the average # of fonts Top 1 Million sites use. We can either collect fresh data with FPDetective or use the existing (~1 year old) data. More on my background relevant to fingerprinting and TBB code base: We recently published a paper called "FPDetective: Dusting the Web for Fingerprinters" (CCS'13) to measure the prevalence of browser fingerprinting on the Internet. As a part of this study, we built instrumented browsers from Chromium and PhantomJS source code and developed a framework to detect fingerprinting (https://github.com/fpdetective/) I also got my hands dirty with the TBB source code to seek vulnerabilities in FP countermeasures. Two ways I found to circumvent existing font limits were as follows: https://trac.torproject.org/projects/tor/ticket/8270#comment:2 https://trac.torproject.org/projects/tor/ticket/5798#comment:13 Other pointers: My website: http://www.esat.kuleuven.be/cosic/?page_id=126 FPDetective website: https://www.cosic.esat.kuleuven.be/fpdetective/ My (first & only) Tor patch: https://trac.torproject.org/projects/tor/ticket/10472 My Tor FAQ profile: http://tor.stackexchange.com/users/731/gacar Looking for your comments, Cheers, Gunes N.B.: I won't be applying to GSoC. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTJmUiAAoJEPb7JcMmVt4g4jAH/2JLUKPGo52JpfsHeMtLZgQm JVoEELKuNVjwJ5KqgO4OhIqpS6yl/cggLsUe19fNrC5I++5w5lGWM3JRqCU/T5OV PLwRrs1lc1wU2zWkcKN/uvZyFys1xAsA2NzyYRZdKOjoGiDI8a3wgYM/o8a5PSt0 +wTJ6OdtRpFuXk9CrxUScx6kbLEYCoQeGcAmQe+ZIUWo6CzeQr/3yP8Jz7B3Uyqq ccSJACFuif2naQFiCDqyuQLIZu/9jMFGbYMg81OhZeeOWhmq4FwCjZOR8bzj8zqV i3N8hFXTRSYLjOg5AWVX+JMsCWJAX3rTrYe6X5GKA/tIm1gMJhwtedfaE38eHOM= =2stA -----END PGP SIGNATURE-----

3 6

Descriptor-id and responsible hidden service directorate. Changes in version 0.2.4.18-rc - 2013-11-16
by Frank Young 21 Mar '14

21 Mar '14

I have noticed that since the release of version 0.2.4.18-rc - 2013-11-16, Attempts to fetch v2 rendezvous service descriptor are failing. The issue seems to get worse as many people are updating their clients. The calculation of decriptor ids based on specification in rend-spec.tx <descriptor-id = H(permanent-id | H(time-period | descriptor-cookie | replica))> doeesn't seems to be correct anymore. All 6 responsible hidden services directorates return 404 to a GET request for /tor/rendezvous2/<base32_encode[descriptor-id]> I search through the tor source for the release version (0.2.4.18-rc - 2013-11-16) in rend_compute_v2_desc_id and rend_client_refetch_v2_renddesc but failed to notice any significant change. Could any member of the dev team respond to to this?

2 3

GSOC- Revamp GetTor
by Kiran Mathew Koshy 21 Mar '14

21 Mar '14

Hi everyone, My name is Kiran Mathew Koshy and I'm a student of IIT Patna, India. I''m interested in participating in Google Summer of Code 2014 under Tor project. GetTor is a service that I had tried a couple of months ago when tor was blocked by our sysadmin, and I believe revamping getTor will have huge impact on avoiding censorship. *TL;DR version*: 1. A system by which a user has multiple routes of obtaining the tor browser- dropbox , mega, google drive, and a couple of other file sharing sites 2. If the user provides their pgp key, an encrypted reply can be sent 3. If the user requests so, the file sent should be password-protected , plus some random data(in a single file) should be added along with the tor browser in order to have variable file sizes. 4. Some file sharing sites(most) allow you to transfer a file between accounts. This is a bit unnecessary, but can be implemented if there is time left. 5. NLP: A very simple natural language processor to process the email and to scavenge for the requested configuration- language, os, file sharing site, etc. Example mail: "please send me a tor browser bundle ( English) that works on Windows. Could you send it through Mega ?" . 6. An email proxy- To counter the small chance that the mail server doesn't allow emails to gettor(a)gettor.torproject.org. Chances of this are low in my opinion, since gmail/ any other mail service is usually available. *Details and explanation*: 1. In most cases, a sysadmin or an ISP can block known bridges, torproject sites, and tor nodes. In this case, *the only way to ensure that a user can access the tor browser software is by allowing multiple sources to download it from. * The practice of blocking File sharing sites is also common, so sites like dropbox, google drive, box, etc are also important. The code will be written in a modular format such that addinga new file sharing site would be equal to adding a couple of urls of their REST API, or at most, writing a new module consisting of 10-15 lines of code. I have worked with the APIs of file sharing sites before, and most are quite similar. 2. If PGP keys are sent, an encrypted reply follows. No brainer. 3. Bundling the software with a file of random size into a password protected tar would prevent snooping based on size of the https request. A little bit far fetched, yes, but good if you are up against your government. This would prove to be cpu intensive and network intensive, since the server will have to encrypt the file and upload it to a file sharing site every time someone requests it. Therefore, this will be limited to one or two instances at any given time. It is also possible to upload multiple instances of encrypted tor browser software, and store the keys in the server. 4. Self Explanatory 5. An NLP would be very simple to implement in this case, in order to fish out the keywords and choose the correct configuration. Example mail: "please send me a tor browser bundle ( English) that works on Windows. Could you send it through Mega ?" . The keywords in this case would be: 1. tor browser bundle. 2. English. 3.Windows 4.Mega. A list of such keywords will be stored on the server. I believe an NLP would be better than the current arrangement. 6. Self Explanatory. Since the current getTor doesn't come close to this, I believe it is best to *rewrite it, reusing select parts*. I havce a good experience in C++ and Python. I completed Google Summer of Code 2013 under Wikimedia Foundation, so this is my second year for GSOC. Since I'm a bit late to apply, I will be submitting this as a proposal right away. Please comment on any changes you would like to incorporate in this. -- Kiran Mathew Koshy Electrical Engineering, IIT Patna, Patna, India

1 0

Tor Browser Weekly IRC meetings moved to 18:00 UTC Fridays
by Mike Perry 20 Mar '14

20 Mar '14

Due to the US Daylight Savings Time changes generating new conflicts for a few people, the Tor Browser team's weekly IRC meeting will now be on Fridays at 18:00 UTC in #tor-dev on irc.oftc.net, starting this Friday, March 21st. We will be snuggling up next to the Huggable^W Pluggable Transports team meeting, which is just before us at 17:00 UTC on alternating Fridays. Their next meeting is March 28th. The hope is that this will help us to work closer with them to polish up the new unified PT-enabled Tor Browser, add new transport types, and otherwise generate PLUR (yeah, I said it). For details on our meeting format, see the original post: https://lists.torproject.org/pipermail/tbb-dev/2014-February/000000.html P.S. We may have to revisit this time again when the EU switches to "Summer Time" on March 30th. Running an hour later in the EU may start to run into people's Friday evening plans, but we'll cross that bridge once it starts burning. -- Mike Perry

1 0

GoSC - Website Fingerprinting project
by Marc Juarez 20 Mar '14

20 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lunar: > Have you read Mike Perry's long blog post on the topic? > https://blog.torproject.org/blog/critique-website-traffic-fingerprinting-at… > > It outlines future research work in evaluating the efficiency of > fingerprinting attacks, and also mention a couple of promising defenses. Yes, I am aware of it and I'm currently working on a study to evaluate the efficiency of these attacks. As Mike Perry said in the post, most of the attacks give an unrealistic advantage to the adversary and probably countermeasures work much better than what has been shown so far. However, some of the results of these articles suggest that there exist coarse-grained traffic features that are invariant to randomized pipelines (RP, SPDY) and thus can still identify web pages (Dyer et. al.). Also, edit-distance based classifiers broke some old versions of the RP implemented in Tor Browser. It's an open problem to see if these features actually uniquely identify web pages in larger worlds than the ones considered in the literature. In any case, link-padding strategies are specially designed to conceal these features with the minimal amount of cover traffic and are becoming affordable in terms of bandwidth. The project I propose would be directed to address this bug ticket: https://trac.torproject.org/projects/tor/ticket/7028 For example, I would like to implement the common building blocks for link-padding countermeasures (such as a "traffic generator controller" in the onion proxy and the entry guard). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHz3kAAoJEGfJ5xfgazlxOwoH/ilP01mjxyyeuPbko/xkKGfw 5gMJGFa0m4StabJ1bhbqJWF2jsu6W2SBCVCqea0emvOvab0WzhuvQvzQb2obZpzr NReUhhiGRhj4xN+2yAL3Vh8zoyZigKtSQPoykwa/AFG7TvIGppHZb0S5ii7Hk/Yf UtwO3Kt3YCGJT3FoKEJQgN2wz82Skbo4Xiw0bknemPFmIkxlxyplkkD0D34OdEYx YPPxRBMuEnpa1H5H3bPMXK55kBP91qS5fg23hsN6Gksy45yhLeiOJZBi0n3nlHD2 xtp4sWdQhTUDFP85kSmbzW/eufuc4WAI6k5KeZtc5YrmIl9eOnAu+tG8Ghu4Vpc= =Rf6n -----END PGP SIGNATURE-----

4 7