- tor-dev - lists.torproject.org

One Valid Next-Generation Onion Address per Private Key
by teor 26 Mar '17

26 Mar '17

Hi all, Most onion service users expect that there is only one valid onion address for their private key. (For example, one address is listed in SSL certificates.) I spoke with Ian, and he said that as part of validating the onion address, we should check if it is a valid point. He said we need to multiply the point by L, and make sure there's no torsion component (that is, that the result is the identity). This avoids the complexity of choosing a canonical point using some lexicographic order, or the complexity of using something like decaf. (Hopefully, Ian will write back if I transcribed things incorrectly.) T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

2 1

Re: [tor-dev] french documentation
by teor 26 Mar '17

26 Mar '17

> On 26 Mar 2017, at 20:58, Thierry Boibary <th.boibary(a)net-c.com> wrote: > > hi, > i'd like to collaborate to Tor, in the hidden services for example Tor2web, Torbirdy, metrics portal ..... Here is some information about these projects: https://www.torproject.org/getinvolved/volunteer.html.en Sorry, it is only in English. Tim > regards > > T Boibary > 06 85 55 34 89 > > <1481836001.1313601483.0> > > > ---- Message d'origine ---- > De : teor <teor2345(a)gmail.com> > À : tor-dev(a)lists.torproject.org > Objet : Re: [tor-dev] french documentation > Date : 24/03/2017 09:24:18 CET > Copie à : Thierry Boibary <th.boibary(a)net-c.com> > > > > On 11 Feb 2017, at 07:55, Thierry Boibary <th.boibary(a)net-c.com> wrote: > > > > hi, > > where can i find french documentation? > > i am expert in systems and networks administration so i'd like working for you, in a domain which needs my capabilities. > > > > help me to find a domain? please > > > > Regards > > T > > Hi Thierry, > > Sorry it has taken a long time for me to reply. > > We have Tor Browser in French: > https://www.torproject.org/projects/torbrowser.html.en#downloads > > We want other documentation in French, but we need people to help! > > What documentation do you want? > > T > > -- > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > xmpp: teor at torproject dot org > ------------------------------------------------------------------------ > > T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

1 0

french documentation
by Thierry Boibary 24 Mar '17

24 Mar '17

hi, where can i find french documentation? i am expert in systems and networks administration so i'd like working for you, in a domain which needs my capabilities. help me to find a domain? please Regards T T Boibary 06 85 55 34 89

2 1

Make Tor Browser Faster GSOC Project
by Tom Ritter 21 Mar '17

21 Mar '17

On Fri, Mar 17, 2017 at 2:07 AM, Kartikey singh <dr.kartikeynrc(a)gmail.com> wrote: > Hi I'm interested in Make Tor Browser Faster gsoc project. Please guide me > for the same. Hi Kartikey, For Tor, the best place to discuss this is on the tor-dev mailing list, which I've included. You should susbcribe and we can talk about this there. As I understand it, student selections have not been made for GSOC yet, so please don't take this as a guarantee that you'll be able to be funded to work on this. Anyway, the topic on the website is a bit ambiguous, so I've attempted to flesh out the project more here: https://storm.torproject.org/shared/URdVCz8eCbBfQzYwG3gaR-KuCvMTIS3zU7emq3A… I'd welcome input from the rest of the tor community on this as well. -tom

2 1

GSoC Draft Proposal
by Mikerah N/A 20 Mar '17

20 Mar '17

Hi all, I have been working on my proposal for a few weeks now and I would like to get some feedback on it. Here it is: https://mikerah.github.io/GSOC2017-Proposal/ Please don't hold back as I would like to have the best possible proposal. Thank you Mikerah

1 0

OnionGatherer: evaluating status of hidden services
by Massimo La Morgia 16 Mar '17

16 Mar '17

Dear members of the Tor community, we are a research group at Sapienza University, Rome, Italy. We do research on distributed systems, Tor, and the Dark Web. As part of our work, we have developed OnionGatherer, a service that gives up-to-date information about Dark Web hidden services to Tor users. OnionGatherer is implemented as a Google Chrome extension coupled with a back-end service running on our servers. As the user surfes the Web, OnionGatherer collects all the URLs from the page and adds a green bullet next ot the URL if the hidden service is up and running, an orange one if the system are currently evaluating the address' status or a red one if the hidden service is down. The status of the hidden services is pulled from our servers, which keep track of all the services found by the users and constantly monitor their status. When a new hidden service is found, OnionGatherer checks its status in real time, informs the user accordingly, and adds it to the database. We believe that OnionGatherer can be very useful to Tor users that are interested in surfing the Dark Web. Indeed, hidden services are born and shut down very frequently, and it is often time consuming and frustrating to check manually which services are still active. We kindky ask if you can help disseminate our project ---the largest is the number of users of OnionGatherer, the largest the database and the best the service we can provide. Currently the software is in Beta version and released on GitHub at the following link: client: https://github.com/rfidlabsapienza/onionGatherer-ChromeExtension server: https://github.com/rfidlabsapienza/onionGatherer-Server Any feedback or issue are really appreciated. Thanks in advance. Best regards, The research group: A. Mei, J. Stefa, M. La Morgia, S. Raponi

7 9

Open tickets
by Karsten Loesing 13 Mar '17

13 Mar '17

Hi everyone, I'm working on some statistics on open tickets of the metrics team in preparation of the Amsterdam meeting, and as part of that I made the following graph on open Trac tickets for all components (except Archived/*): https://people.torproject.org/~karsten/volatile/open-tickets.pdf Not sure if this graph is useful for anybody else. But if it is, is there a way to make it even more useful? And just in case this is useful, here's the graphed data: https://people.torproject.org/~karsten/volatile/open-tickets.csv All the best, Karsten

1 0

GSoC 2017 Project Idea
by Sakchham Sharma 13 Mar '17

13 Mar '17

Greetings Tor Community, I am Sakchham Sharma a CS Undergrad student, I intend to participate in GSoC 2017 and contribute to the Tor Project. The Tor Project as so now is quite well known among the people with a technical background, but however, the people who don't belong to this category have little or no idea about Tor, they are perhaps the people that would benefit the most from Tor. So in order to help people better understand about Tor, that how it is different from their VPN or Proxy service, I intend to an UI Redesign of the Orbot app for android, as of now it has a minimalistic UI and several UI glitches, an UI that also gives the users a subtle idea as to how tor works with be informative and should help more people know more about Tor, I would be grateful if I could get suggestions/improvements on the above idea. Thank you. <https://mailtrack.io/> Sent with Mailtrack <https://mailtrack.io/install?source=signature&lang=en&referral=sakchhams@gm…>

3 3

GSOC Contribution Into and Help
by Anshul Malik 12 Mar '17

12 Mar '17

Hi there! I am Anshul, computer science undergrad from NIT, Kurukshetra, India. I really like using tor, always wanted to contribute somhow, and here google gives me a chance. I am a good programmer, have been doing projects with node, recently also started with python django. I have also contributed to firefox devtools. I wish to contribute to *Ahima- Hidden Service Search* I saw ideas list on the page, I can definitely work on - Automate blacklisting - Add hidden services function - Elastic Search Just need a headstart, Please let me know where can I find contribution guide and some more information about Ahima, I am currently studying the architecture and codebase from github. Thanks

2 1

GSoC 17- Intro
by Pasan Chamikara 12 Mar '17

12 Mar '17

Hi, I am Pasan Chamiekara, a final year undergraduate in BSc in Biological Science at University of Colombo and a final year undergraduate at Sri Lanka Institute of Information Technology (BSc Hons in IT specializing in Cyber Security). (Simply a dual degree expectee) . I do pocess 7 months of completed internship at Sri Lanka CERT | CC as an Intern - Information Security. My main research interests are in automated malware analysis, Intrusion detection and Neural Networking. I do pocess strong skills in html, css, php, javascript, python, C, C++ ,java, ASM and intermediate level skills in Android,scala. I am interested in the following components, *Ahmia - Hidden Service Search* Regards Pasan

2 1

Re: [tor-dev] Flashproxy has been Deactivated by Stanford? Why?
by David Fifield 12 Mar '17

12 Mar '17

On Tue, Dec 20, 2016 at 01:21:04AM +0800, tomli(a)riseup.net wrote: > It turned out that the entire code has been commented out and apparently > Flashproxy became > out of service. Why? Has the project discontinued, or just down for > maintenance? Flash proxy is basically retired now. It was removed from Tor Browser a year ago (https://bugs.torproject.org/17428) after it had been supplanted by more effective transports. I don't know why there was a blog post on December 16 promoting flash proxy, because it's no longer used. Even when flash proxy was part of Tor Browser, it had very few users (less than 100; see https://metrics.torproject.org/userstats-bridge-transport.html?start=2013-0…) probably because of the difficulty of running it as a client (https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/Flash…) Compare those user numbers to meek (current about 10K) or obfs4 (30K). The reason I haven't asked people to stop running the flash proxy badge is we're working on a new pluggable transport along the same lines but without the usability challenges: https://trac.torproject.org/projects/tor/wiki/doc/Snowflake. I was thinking about adapting existing flash proxy badges to provide capacity to Snowflake instead. This would go for Cupcake as well. The need to get the badge running again hasn't been pressing because Snowflake isn't deployed yet, but we're getting close. The badge was deactivated by Stanford (without my knowledge, but I found out a while ago). I arranged with them to move it to alternate hosting and have them install a redirect, but that has been a low priority behind other work on Snowflake. I'm sorry about the confusion. If I get some time I'll add a notice to the flash proxy main page saying that it's been retired.

2 2

Flag blocked websites
by Boter42 11 Mar '17

11 Mar '17

Hi, I think it would be important to have a way to flag/report those websites that can't be access by the users while they're using the tor browser. Is there already a solution to do this? Do you think it would be a good tool? It would be great to have an updated records of this kind of websites so that we can push website owners to make the Tor user-experience as smooth as possible. Thanks

3 7

[PATCH] prop224: Trivial improvements to HS ntor section
by George Kadianakis 09 Mar '17

09 Mar '17

Hey David, please check my `prop224-ntor` torspec branch for some basic improvements to the HS ntor section that came up while implementing it. Here it is: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224-ntor Let me know if you like them and I will merge them ASAP. Cheers!

1 1

Tor Arch Diagrams
by chelsea komlo 09 Mar '17

09 Mar '17

Hello All, I've published object diagrams created from a conversation with Nick at the last Tor meeting, along with the original sketches (hopefully very similar). github.com/chelseakomlo/tor_arch The plan for these is to include them into documentation. These should definitely evolve along with tor's architecture, so please don't think of them as set in stone. A couple questions/comments: - What else should be included? The most important thing is that these are good visual assets for future discussions on topics such as modularization, where code/responsibility should belong, if any new structures are needed, etc. - Some of these may need more information. For example, the scheduler diagram. - If object diagrams do not capture tor's architecture accurately, we can also look at event modeling. This would model what happens as different events occur from start to finish in the tor network. - If it is useful for these to be UML, I can do that. But more importantly is that they are useful. Feedback welcome! Chelsea

2 2

Tor in Google Summer of Code 2017
by Damian Johnson 07 Mar '17

07 Mar '17

Interested in coding on Tor and getting paid for it by Google? If you are a student, we have good news for you: we have been accepted as a mentoring organization for Google Summer of Code 2017! https://summerofcode.withgoogle.com/organizations/5675829762719744/ Here's the facts: GSoC gives you the opportunity to work on your own Tor-related coding project with one of the Tor developers as your mentor. Your mentor will help you when you're stuck and guide you in becoming part of the Tor community. Google pays you for the three months of your project, so that you can focus on coding and don't have to worry about how to pay your bills. https://www.torproject.org/getinvolved/volunteer.html.en#Projects Did we catch your attention? These are your next steps: Go look at the Google Summer of Code FAQ [1] to make sure you are eligible to participate. Have a look at our ideas list [2] to see if one of those projects matches your interests. If there is no project on that list that you'd want to work on, read the documentation on our website [3] and make up your own! Come to #tor-dev on OFTC [4] or let us know about your project idea here. Communication is essential to success in the summer of code, and we're unlikely to accept students we haven't heard from before reading their application. So really, speak up on this list or come to our IRC channel and talk to us! Finally, write down your project idea using our template [5] and submit your application to Google before March 25th [6]. We are looking forward to discussing your project idea with you! [1] https://developers.google.com/open-source/gsoc/faq [2] https://www.torproject.org/getinvolved/volunteer.html.en#Coding [3] https://www.torproject.org/docs/documentation.html.en#UpToSpeed [4] https://www.torproject.org/about/contact.html.en#irc [5] https://www.torproject.org/about/gsoc.html.en#Template [6] https://developers.google.com/open-source/gsoc/timeline

2 2

Proposal: Directory Compression Scheme Negotiation
by Alexander Færøy 06 Mar '17

06 Mar '17

Hello, Here's my draft proposal for extending the directory protocol to support compression scheme negotiation using the semantics of the HTTP protocol. This is part of the work that Nick and I are looking into for our Sponsor4 design. All feedback is highly appreciated :-) Cheers, Alex. Filename: xxx-directory-compression-scheme-negotiation.txt Title: Directory Compression Scheme Negotiation Author: Alexander Færøy Created: 2017-03-06 Status: Draft Target: N/A 0. Overview This document describes a method to provide and use different compression schemes in Tor's directory specification[0] and let it be up the client and server to negotiate a mutually supported scheme using the semantics of the HTTP protocol. Furthermore this proposal also extends Tor's directory protocol with support for the LZMA2 and Zstandard compression schemes. 1. Motivation Currently Tor serves each directory client with its different document flavours in either an uncompressed format or, if the client adds a ".z"-suffix to the URL file path, a zlib-compressed document. This have historically been non-problematic, but it disallows us from easily extending the set of supported compression schemes. Some of the problems this proposal is trying to aid: - We currently only support zlib-based compression schemes and there is no way for directory servers or clients to announce which compression schemes they support. Zlib might not be the ideal compression scheme for all purposes. - It is not easily possible to add support for additional compression schemes without adding additional file extensions or flavours of the directory documents. - In low-bandwidth and/or low-memory client scenarios it is useful to be able to limit the amount of supported compression schemes to have a client only support the most efficient compression scheme for the given use-case and have the directory servers support the most commonly available compression schemes used throughout the network. - We add support for the LZMA2 compression scheme, which yields better compressed size and decompression time at the expensive of higher compression time and higher memory usage. - We add support for the Zstandard compression scheme, which yields better compression ratio than GZip, but slightly worse than LZMA2, but with a smaller CPU and memory footprint than LZMA2. 2. Analysis We investigated the compression ratio, memory usage, memory allocation strategies, and execution time for compression and decompression of the GZip, BZip2, LZMA2, and Zstandard compression schemes at compression levels 1 through 9. The data used in this analysis can be found in [1] and the `bench` tool for generating the data can be found in [2]. During the preparation for this proposal Nick have analysed compressing consensus diffs using both GZip, LZMA2, and Zstandard. The result of Nick's analysis can be found in [3]. We must continue to support both "gzip", "deflate", and "identity" which are the currently available compression schemes in the Tor network. Further to enhance the compression ratio Nick have also worked on proposal #274 (Rotate onion keys less frequently), #275 (Stop including meaningful "published" time in microdescriptor consensus), #276 (Report bandwidth with lower granularity in consensus documents), and #277 (Detect multiple relay instances running with same ID) which all aid in making our consensus documents less dynamic. 3. Proposal We extend the directory client requests to include the "Accept-Encoding" header as part of its request. The "Accept-Encoding" header should contain a comma-separated list of names of the compression schemes of which the client supports. For example: GET / HTTP/1.0 Accept-Encoding: zstd, xz, gzip, deflate When a directory server receives a request with the "Accept-Encoding" header included it must decide on a mutually supported compression scheme and add the "Content-Encoding" header to its response and thus notifying the client of its decision. The "Content-Encoding" header can at most contain one supported compression scheme. If no mutual compression scheme can be negotiated the server must respond with an HTTP error status code of 415 "Unsupported Media Type". For example: HTTP/1.0 200 OK Content-Length: 1337 Connection: close Content-Encoding: zstd Currently supported compression scheme names includes "identity", "gzip", and "deflate". This proposal adds two additional compression scheme named "xz" (LZMA2) and "zstd" (Zstandard). All compression scheme names are case-insensitive. The "deflate", "gzip", and "identity" compression schemes must be supported by directory servers for backwards compatibility. Additionally, when a client, that supports this proposals, makes a request to a directory document with the ".z"-suffix it must send an ordered set of supported compression schemes where the last elements in the set contains compression schemes that are supported by all of the currently available Tor nodes ("gzip", "deflate", "identity"). In this way older relays will simply respond with the document compressed using zlib deflate without any prior knowledge of the newly added compression schemes. The "Content-Length" header contains the number of compressed bytes sent to the client. The new compression schemes will be available for directory clients over both clearnet and BEGIN_DIR-style connections. 4. Security Implications 4.1 Compression and Decompression Bombs We currently detect compression and decompression "bombs" and must continue to do so with any additional compression schemes that we add. The detection of compression and decompression bombs are handled in `is_compression_bomb()` in torgzip.c and the same functionality is used both for compression and decompression. These functions must be extended to support LZMA2 and Zstandard. 4.2 Detection of Compression Algorithms To ensure that we do not pass compressed data through the incorrect decompression handler, when we have received data from another peer, Tor tries to detect the compression scheme in `detect_compression_method()`` in torgzip.c. This function should be extended to also detect the LZMA2 and Zstandard formats. Possible methods of applying this detection is looking at xz-tools, zstd's CLI, and the libmagic 'compress' module. 4.3 Fingerprinting All clients should aim at supporting the same set of supported compression schemes to avoid fingerprinting. 5. Compatibility This proposal does not break any backwards compatibility. Tor will continue to support serving uncompressed and zlib-compressed objects using the method defined in the directory specification[0], but will allow newer clients to negotiate a mutually supported compression scheme. 6. Performance and Scalability Each newly added compression scheme adds to the compression cache of a relay, which increases the memory requirements of a relay. The LZMA2 compression scheme yields better compression ratio at the expense of higher memory and CPU requirements for compression and slightly higher memory and CPU requirements for decompression. The Zstandard compression scheme yields better compression ratio than GZip does, but does not suffer from the same high CPU and memory requirements for compression as LZMA2 does. Because of the high requirements for CPU and memory usage for LZMA2 it is possible that we do not support this scheme for all available documents or that we only support it in situations where it is possible to pre-compute and cache the compressed document. 7. References [0]: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt [1]: https://docs.google.com/spreadsheets/d/1devQlUOzMPStqUl9mPawFWP99xSsRM8xWv7… [2]: https://gitlab.com/ahf/tor-sponsor4-compression [3]: https://github.com/nmathewson/consensus-diff-analysis -- Alexander Færøy

1 0

Unable to Join the IRC Channel #tor.
by Siddharth Bhayana 01 Mar '17

01 Mar '17

It's my first time entering an IRC channel and after having read the documentation for ChatZilla, I'm still unable to find my way. These are the steps I've been following: 1) Open ChatZilla extension on Firefox. 2) Click on IRC -> Join Channel. 3) The two fields that appear are - Network and Channel. From this point on, I have no idea as to how to proceed. Any help would be appreciated. -- Thanks and regards Siddharth Bhayana

2 2

Proposal 276: Report bandwidth with lower granularity in consensus documents
by Nick Mathewson 01 Mar '17

01 Mar '17

Filename: 276-lower-bw-granularity.txt Title: Report bandwidth with lower granularity in consensus documents Author: Nick Mathewson Created: 20-Feb-2017 Status: Open Target: 0.3.1.x-alpha 1. Overview This document proposes that, in order to limit the bandwidth needed for networkstatus diffs, we lower the granularity with which bandwidth is reported in consensus documents. Making this change will reduce the total compressed ed diff download volume by around 10%. 2. Motivation Consensus documents currently report bandwidth values as the median of the measured bandwidth values in the votes. (Or as the median of all votes' values if there are not enough measurements.) And when voting, in turn, authorities simply report whatever measured value they most recently encountered, clipped to 3 significant base-10 figures. This means that, from one consensus to the next, these weights very often and with little significance: A large fraction of bandwidth transitions are under 2% in magnitude. As we begin to use consensus diffs, each change will take space to transmit. So lowering the amount of changes will lower client bandwidth requirements significantly. 3. Proposal I propose that we round the bandwidth values as they are placed in the votes to two no more than significant digits. In addition, for values beginning with decimal "2" through "4", we should round the first two digits the nearest multiple of 2. For values beginning with decimal "5" though "9", we should round to the nearest multiple of 5. This change does not require a consensus method; it will take effect once enough authorities have upgraded. 4. Analysis The rounding proposed above will not round any value by more than 5%, so the overall impact on bandwidth balancing should be small. In order to assess the bandwidth savings of this approach, I smoothed the January 2017 consensus documents' Bandwidth fields, using scripts from [1]. I found that if clients download consensus diffs once an hour, they can expect 11-13% mean savings after xz or gz compression. For two-hour intervals, the savings is 8-10%; for three-hour or four-hour intervals, the savings only is 6-8%. After that point, we start seeing diminishing returns, with only 1-2% savings on a 72-hour interval's diff. [1] https://github.com/nmathewson/consensus-diff-analysis 5. Open questions: Is there a greedier smoothing algorithm that would produce better results? Is there any reason to think this amount of smoothing would not be save? Would a time-aware smoothing mechanism work better?

3 5

[release] Onionoo 4.0-1.2.0
by iwakeh 28 Feb '17

28 Feb '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! Another release of Onionoo is available: https://dist.torproject.org/onionoo-4.0-1.2.0/ The protocol version increased to 4.0, because Onionoo now accepts searches for IPv6 addresses even without leading or enclosing square brackets. Onionoo's web-page (as well as JavaDoc) is now adapted to the new style of Tor Metrics [0]. Take a look at new version on one of Onionoo's mirrors [1] or [2]. Please direct comments and questions to the metrics-team mailing list [4]. Cheers, iwakeh [0] https://metrics.torproject.org [1] https://onionoo.torproject.org [2] https://onionoo.thecthulhu.com [3] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYtZgQAAoJEPeEx9Sa/gviD2oQAMdFYbAU0aIljrTfKUB9yNZX qLc9AtjmSL9F6sgrAGGqwokFtw+LtdoxkCwyRvIA6xSPxFqkR31ZIoMxj+E1hwXU hRp3GQcL9uWhImC2ZK3+pllMUpuF4BAzz1lq2AWlQGq4WCO9E8ER+FTLw5XDwZV/ dTHsh+3gyD4WIZdVCSb27hgmS7YqylTZys+UhRM/ouxl8b4CenMCAYNQ25e1/XNH Rf2C/LOa6UEfd+/wOJ+C/br4cR1aLBysC8XUvgfUm+f6hA2jPDAGUTBJvqK3IPVB d/UfFkWeq+FZZfN/rQ0ms8vQ9snJLJAH7RQsCc7ZrnbYUjaxC6/qLnYLfD5BdNNb pXzIDNHM5ZLKMj1EgdKBa0kfbMobj1d1/2kHT0J60jefiwPov408oSyHmezjft2o O0cpjwhy2LMbTgyTARSQSmpQjO7+7N6ofWxT6ZrN+9UCr54mQ9GRDUCyex7Wz6ri CwQA3D18pU8ig8JDpfQjGSmmqDjkl8Ph6bfyu/CksK9up8Euv1KdDiLWD7XYQaGl NBXLGzKUGRxi1J+ed81NTdccoUOgA5+LavSp0ByRM3h/cFW7Ns9VHFydlgdNKPIg gsJQ1Sg/ayVBwEN7nEL55Ul4QQzAC+REHQE+2ct2lJoNvL/y6Wgh4k/xDlPdRNrQ vjVWNCPGVTFKZXXBibYN =BVbr -----END PGP SIGNATURE-----

1 1

I would like collaborate with you
by Berenike Grace 28 Feb '17

28 Feb '17

Hi, I’m Veronica Minati, an Italian student of Computer Science at the Università degli studi di Udine. I've a bachelor degree and now I'm at the last year of the Master degree. Some teachers and colleagues suggested me to partecipate at an opensource project, to challenge myself and learn more. I'm interested in cyber security and cryptography and I dream that one day I will work in this area. I'm studying your projects and I would like to cooperate with you, for the GSoC and I hope that I will be able to continue the work in the future. I'm sure that this experience will grow my background. I'm skilled in Java programming but I've studied also other programming languages. I would like to offer to collaborate at the Onionoo project with karsten and iwakeh, May I ask you how can I be helpful? What knowledge should I have to work on that project? Thank you so much! Veronica Minati. Ps: In the meantime I will follow you in the IRC channel, my nickname is versa!

2 1

GSOC 2017
by Mikerah N/A 27 Feb '17

27 Feb '17

Hi all, My name is Mikerah and I would love to work for the Tor Project during the summer through Google Summer of Code. The main project that I am considering contributing to is the Ahmia search engine for Tor hidden services. I would like to contribute to automating backlisting, improving language detection and adding a query language. This is simply a really rough idea of what I want to do. My main programming language is Python but I do have some experience writing code in Java, C/C++ and R. I have also built a few web applications using django that can be seen here: https://github.com/Mikerah. I would like to discuss more about what I would possibly be doing with the likely mentors Juha Nurmi and George. Thanks.

1 0

Proposal 274: Rotate onion keys less frequently
by Nick Mathewson 27 Feb '17

27 Feb '17

Filename: 274-rotate-onion-keys-less.txt Title: Rotate onion keys less frequently. Author: Nick Mathewson Created: 20-Feb-2017 Status: Open Target: 0.3.1.x-alpha 1. Overview This document proposes that, in order to limit the bandwidth needed for microdescriptor listing and transmission, we reduce the onion key rotation rate from the current value (7 days) to something closer to 28 days. Doing this will reduce the total microdescriptor download volume by approximately 70%. 2. Motivation Currently, clients must download a networkstatus consensus document once an hour, and must download every unfamiliar microdescriptor listed in that document. Therefore, we can reduce client directory bandwidth if we can cause microdescriptors to change less often. Furthermore, we are planning (in proposal 140) to implement a diff-based mechanism for clients to download only the parts of each consensus that have changed. If we do that, then by having the microdescriptor for each router change less often, we can make these consensus diffs smaller as well. 3. Analysis I analyzed microdescriptor changes over the month of January 2017, and found that 94.5% of all microdescriptor transitions were changes in onion key alone. Therefore, we could reduce the number of changed "m" lines in consensus diffs by approximately 94.5% * (3/4) =~ 70%, if we were to rotate onion keys one-fourth as often. The number of microdescriptors to actually download should decrease by a similar number. This amount to a significant reduction: currently, by back-of-the-envelope estimates, an always-on client that downloads all the directory info in a month downloads about 449MB of compressed consensuses and something around 97 MB of compressed microdescriptors. This proposal would save that user about 12% of their total directory bandwidth. If we assume that consensus diffs are implemented (see proposal 140), then the user's compressed consensus downloads fall to something closer to 27 MB. Under that analysis, the microdescriptors will dominate again at 97 MB -- so lowering the number of microdescriptors to fetch would save more like 55% of the remaining bandwidth. [Back-of-the-envelope technique: assume every consensus is downloaded, and every microdesc is downloaded, and microdescs are downloaded in groups of 61, which works out to a constant rate.] We'll need to do more analysis to assess the impact on clients that connect to the network infrequently enough to miss microdescriptors: nonetheless, the 70% figure above ought to apply to clients that connect at least weekly. (XXXX Better results pending feedback from ahf's analysis.) 4. Security analysis The onion key is used to authenticate a relay to a client when the client is building a circuit through that relay. The only reason to limit their lifetime is to limit the impact if an attacker steals an onion key without being detected. If an attacker steals an onion key and is detected, the relay can issue a new onion key ahead of schedule, with little disruption. But if the onion key theft is _not_ detected, then the attacker can use that onion key to impersonate the relay until clients start using the relay's next key. In order to do so, the attacker must also impersonate the target relay at the link layer: either by stealing the relay's link keys, which rotate more frequently, or by compromising the previous relay in the circuit. Therefore, onion key rotation provides a small amount of protection only against an attacker who can compromise relay keys very intermittently, and who controls only a small portion of the network. Against an attacker who can steal keys regularly it does little, and an attacker who controls a lot of the network can already mount other attacks. 5. Proposal I propose that we move the default onion key rotation interval from 7 days to 28 days, as follows. There should be a new consensus parameter, "onion-key-rotation-days", measuring the key lifetime in days. Its minimum should be 1, its maximum should be 90, and its default should be 28. There should also be a new consensus parameter, "onion-key-grace-period-days", measuring the interval for which older onion keys should still be accepted. Its minimum should be 1, its maximum should be onion-key-rotation-days, and its default should be 7. Every relay should list each onion key it generates for onion-key-rotation-days days after generating it, and then replace it. Relays should continue to accept their most recent previous onion key for an additional onion-key-rotation-days days after it is replaced.

3 2

Proposal 275: Stop including meaningful "published" time in microdescriptor consensus
by Nick Mathewson 27 Feb '17

27 Feb '17

Filename: 275-md-published-time-is-silly.txt Title: Stop including meaningful "published" time in microdescriptor consensus Author: Nick Mathewson Created: 20-Feb-2017 Status: Open Target: 0.3.1.x-alpha 1. Overview This document proposes that, in order to limit the bandwidth needed for networkstatus diffs, we remove "published" part of the "r" lines in microdescriptor consensuses. The more extreme, compatibility-breaking version of this idea will reduce ed consensus diff download volume by approximately 55-75%. A less-extreme interim version would still reduce volume by approximately 5-6%. 2. Motivation The current microdescriptor consensus "r" line format is: r Nickname Identity Published IP ORPort DirPort as in: r moria1 lpXfw1/+uGEym58asExGOXAgzjE 2017-01-10 07:59:25 \ 128.31.0.34 9101 9131 As I'll show below, there's not much use for the "Published" part of these lines. By omitting them or replacing them with something more compressible, we can save space. What's more, changes in the Published field are one of the most frequent changes between successive networkstatus consensus documents. If we were to remove this field, then networkstatus diffs (see proposal 140) would be smaller. 3. Compatibility notes Above I've talked about "removing" the published field. But of course, doing this would make all existing consensus consumers stop parsing the consensus successfully. Instead, let's look at how this field is used currently in Tor, and see if we can replace the value with something else. * Published is used in the voting process to decide which descriptor should be considered. But that is takend from vote networkstatus documents, not consensuses. * Published is used in mark_my_descriptor_dirty_if_too_old() to decide whether to upload a new router descriptor. If the published time in the consensus is more than 18 hours in the past, we upload a new descriptor. (Relays are potentially looking at the microdesc consensus now, since #6769 was merged in 0.3.0.1-alpha.) Relays have plenty of other ways to notice that they should upload new descriptors. * Published is used in client_would_use_router() to decide whether a routerstatus is one that we might possibly use. We say that a routerstatus is not usable if its published time is more than OLD_ROUTER_DESC_MAX_AGE (5 days) in the past, or if it is not at least TestingEstimatedDescriptorPropagationTime (10 minutes) in the future. [***] Note that this is the only case where anything is rejected because it comes from the future. * client_would_use_router() decides whether we should download a router descriptor (not a microdescriptor) in routerlist.c * client_would_use_router() is used from count_usable_descriptors() to decide which relays are potentially usable, thereby forming the denominator of our "have descriptors / usable relays" fraction. So we have a fairly limited constraints on which Published values we can safely advertize with today's Tor implementations. If we advertise anything more than 10 minutes in the future, client_would_use_router() will consider routerstatuses unusable. If we advertize anything more than 18 hours in the past, relays will upload their descriptors far too often. 4. Proposal Immediately, in 0.2.9.x-stable (our LTS release series), we should stop caring about published_on dates in the future. This is a two-line change. As an interim solution: We should add a new consensus method number that changes the process by which Published fields in consensuses are generated. It should set all all Published fields in the consensus should be the same value. These fields should be taken to rotate every 15 hours, by taking consensus valid-after time, and rounding down to the nearest multiple of 15 hours since the epoch. As a longer-term solution: Once all Tor versions earlier than 0.2.9.x are obsolete (in mid 2018), we can update with a new consensus method, and set the published_on date to some safe time in the future. 5. Analysis To consider the impact on consensus diffs: I analyzed consensus changes over the month of January 2017, using scripts at [1]. With the interim solution in place, compressed diff sizes fell by 2-7% at all measured intervals except 12 hours, where they increased by about 4%. Savings of 5-6% were most typical. With the longer-term solution in place, and all published times held constant permanently, the compressed diff sizes were uniformly at least 56% smaller. With this in mind, I think we might want to only plan to support the longer-term solution. [1] https://github.com/nmathewson/consensus-diff-analysis

3 2

Proposal 277: Detect multiple relay instances running with same ID
by Nick Mathewson 24 Feb '17

24 Feb '17

Filename: 277-detect-id-sharing.txt Title: Detect multiple relay instances running with same ID. Author: Nick Mathewson Created: 20-Feb-2017 Status: Open Target: 0.3.?? 1. Overview This document proposes that we detect multiple relay instances running with the same ID, and block them all, or block all but one of each. 2. Motivation While analyzing microdescriptor and relay status transitions (see proposal XXXX), I found that something like 16/10631 router identities from January 2017 were apparently shared by two or more relays, based on their excessive number of onion key transitions. This is probably accidental: and if intentional, it's probably not achieving whatever the relay operators intended. Sharing identities causes all the relays in question to "flip" back and forth onto the network, depending on which one uploaded its descriptor most recently. One relay's address will be listed; and so will that relay's onion key. Routers connected to one of the other relays will believe its identity, but be suspicious of its address. Attempts to extend to the relay will fail because of the incorrect onion key. No more than one of the relays' bandwidths will actually get significant use. So clearly, it would be best to prevent this. 3. Proposal 1: relay-side detection Relays should themselves try to detect whether another relay is using its identity. If a relay, while running, finds that it is listed in a fresh consensus using an onion key other than its current or previous onion key, it should tell its operator about the problem. (This proposal borrows from Mike Perry's ideas related to key theft detection.) 4. Proposal 2: offline detection Any relay that has a large number of onion-key transitions over time, but only a small number of distinct onion keys, is probably two or more relays in conflict with one another. In this case, the operators can be contacted, or the relay blacklisted. We could build support for blacklisting all but one of the addresses, but it's probably best to treat this as a misconfiguratino serious enough that it needs to be resolved.

1 0

Proposing "Post-Quantum safe handshake implementation" as GSoc Project
by Jaskaran Singh 23 Feb '17

23 Feb '17

Hi, My name is Jaskaran, and I'm an Electronics Engineering undergrad in India. I'm a privacy, anonymity and FOSS supporter. I've worked in the past with the Libreoffice project during the Google Summer of Code 2016. This year I'm interested to work with the TOR project as a part of GSoC. I'm particularly interested to work on making TOR Handshakes Post-Quantum Safe. I feel that this should be implemented at the earliest because adversaries could store the network traffic and decrypt it later on using Quantum Computers when they're invented. So here's what I think the task would comprise of : 1. Add a new CREATE2V and CREATED2V cell that can support 2240 bytes of HDATA (according to NewHope-Simple algorithm[1]). Add facility for multiple EXTEND2/EXTENDED2 cells to be sent when the handshake data doesn't fit into a single cell. 2. Implement the NewHope-Simple algorithm[1] because we'll not be able to use the Vanilla NewHope as it is protected by some patents. I wasn't able to find any implementation of NewHope Simple. So can the Vanilla NewHope Implementation be tweaked to convert it into NewHope Simple? Or would we have to write it from ground up? I don't know about the patent laws regarding it. 3. Finally, generate test vectors and check for any bottlenecks. Improve efficiency and check for any vulnerabilities in the implementation that could be exploited by the adversary. I'd like to know your views on this. Suggestions, comments, criticism are all welcome. References [1] https://eprint.iacr.org/2016/1157.pdf PS: There's Something I noticed while reading the proposal. The portions don't add up to the size of the cell. Here's aSigned fix for it. commit a55692fcd93e3f064f1fffe24796dc747e4870e1 Author: Jaskaran Singh <jvsg1303(a)gmail.com> Date: Sat Feb 18 13:32:32 2017 +0530 Fix HDATA sizes in proposal 270 diff --git a/proposals/270-newhope-hybrid-handshake.txt b/proposals/270-newhope-hybrid-handshake.txt index ccf3390..c0f36ae 100644 --- a/proposals/270-newhope-hybrid-handshake.txt +++ b/proposals/270-newhope-hybrid-handshake.txt @@ -432,7 +432,7 @@ Depends: prop#220 prop#249 prop#264 prop#270 HTYPE := 0x0003 [2 bytes] HLEN := 0x0780 [2 bytes] HDATA := CLIENT_HDATA [1920 bytes] - IGNORED := 0x00 [194 bytes] + IGNORED := 0x00 [190 bytes] } [XXX do we really want to pad with IGNORED to make CLIENT_HDATA the @@ -485,7 +485,7 @@ Depends: prop#220 prop#249 prop#264 prop#270 NSPEC := 0x00 [1 byte] HTYPE := 0xFFFF [2 bytes] HLEN := 0x0000 [2 bytes] - HDATA := 0x00[172] [172 bytes] + HDATA := 0x00[172] [174 bytes] } The client sends this to the server to extend the circuit from, and that @@ -525,7 +525,7 @@ Depends: prop#220 prop#249 prop#264 prop#270 NSPEC := 0x00 [1 byte] HTYPE := 0xFFFF [2 bytes] HLEN := 0x0000 [2 bytes] - HDATA := SERVER_HDATA[1940,2112] [172 bytes] + HDATA := SERVER_HDATA[1940,2112] [174 bytes] } Regards, Jaskaran

3 3