- tor-dev - lists.torproject.org

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

txtorcon 'all_routers' issue
by meejah 23 Feb '17

23 Feb '17

As per https://github.com/meejah/txtorcon/issues/203 all released versions of txtorcon that have TorState.all_routers will, upon a NEWCONSENSUS event, make this set empty. There is already a fix on master for the real issue and it will be in the next release. For users of released versions there is a workaround, pointed out by evilaliv3: simply use TorState.routers.values() instead. Cheers, meejah

1 0

List of Tor Exit IP address: Is this available from Tor Control Port
by Fabio Pietrosanti (naif) - lists 22 Feb '17

22 Feb '17

Hi all, is the list of Tor Exit IP addresses available from Tor Control Port or only from https://check.torproject.org/exit-addresses via TorDNSEL ? -naif

2 1

announcing: txmix, a twisted python mixnet library
by dawuud 19 Feb '17

19 Feb '17

Hi. I'd like to announce txmix, a library for writing mixnets in python. https://github.com/applied-mixnetworks/txmix txmix is GPL3 licensed and currently depends on: sphinxmixcrypto, Twisted, txtorcon, attrs, eliot and Tor Project's chutney (for integration tests). txmix allows you to write mixnets with reduced code complexity and transport agnosticism... however I've choosen to focus my development efforts on the Tor onion transport for several reasons, the onion transport has some properties which the UDP transport does not: - reliability - forward secrecy - NAT penetration Additionally the Tor anonymity properties are a welcome bonus since they aren't really overlapping with those of the mixnet, they are vulnerable to different types of attacks and accomodate for totally different threat models. Currently txmix has some integration tests that use chutney to spin up a local 25 relay tor network; builds a mixnet using onion services as the transport and then tests functionality by sending and receiving messages on the mixnet. future development ------------------ - txmix could certainly be used to write various kinds of mixnets, however, we are missing a PKI. Without some kind of public key infrastructure how will mix clients learn about mix public keys? - sphixmixcrypto library needs improvements that would allow us to specify more message types such as dummy/cover traffic message and heartbeat messages. These of course are essential for the defense against certain known active attacks against some mix types. questions, code review and pull requests welcome. David Stainton

1 0

Netflow padding
by grarpamp 19 Feb '17

19 Feb '17

Are these the current / recommended paper refs for eyeballing things on this to date? torspec/proposals/251-netflow-padding.txt torspec/proposals/254-padding-negotiation.txt

2 1