- tor-dev - lists.torproject.org

Quantum-safe Hybrid handshake for Tor
by Zhenfei Zhang 29 Apr '16

29 Apr '16

Hi list, This is a proposal to use quantum-safe hybrid handshake for Tor communications. Given NSA's recent announcement on moving towards quantum-safe cryptography, it would be nice to have a quantum-safe feature for Tor. The idea of the quantum-safe hybrid handshake is to combine both classical key exchange and a key encapsulation mechanism (KEM) instantiated by a quantum safe encryption algorithm, so that the combination gives both (classical) authentication and quantum safety. In a bit more details, the client and the server agrees on a classic pre-master secret, $c$, using the ntor protocol. In parallel, client generates a public/private key pair of the quantum-safe encryption algorithm, and send the public key to the server. The server picks a random string, $q$, encrypts it with the public key and send the ciphertext back to the client. The final secret is the output of KDF(c|q). This proposal defeats the harvest-then-decrypt attack with a minimum impact to the existing ntor protocol. An adversary needs to be able to break the quantum-safe encryption algorithm to learn q. On the other hand, if the quantum-safe encryption algorithm turns out to be not secure, the protocol is still as secure as ntor protocol. In other words, it will at least do no harm to the current security. In addition, this is a modular design that allows us to use any quantum-safe cryptographic primitives. As a proof of concept, we instantiated the protocol with NTRUEncrypt lattice-based crypto. We implemented the the protocol with NTRU parameters that gives 128 bits security. The code is available at https://github.com/NTRUOpenSourceProject/ntru-tor Please find the attachment for the request to change the feature. The proof of the protocol can be found at: https://eprint.iacr.org/2015/287.pdf Some known issue: 1. cell size. As far as we know, all quantum-safe encryption algorithms have large key and/or ciphertext size that exceeds the cell size ~500. So this protocol needs to transmit multiple cells, no matter which quantum-safe encryption algorithm we chose. This is addressed by "Proposal 249: Allow CREATE cells with >505 bytes of handshake data". 2. quantum-safe authentication: there is no quantum-safe authentication in this protocol. We believe that authentication can wait, as future (quantum) adversary cannot come back to present time and break authentication. Hence, we use ntor authentication to keep the proposal compact and simple. It will be a future work after this proposal. Thanks for your time, and happy holidays! Zhenfei Zhang Security Innovation.

9 26

Re: [tor-dev] Latest state of the guard algorithm proposal (prop259) (April 2016)
by George Kadianakis 29 Apr '16

29 Apr '16

Fan Jiang <fanjiang(a)thoughtworks.com> writes: > [ text/plain ] > On Fri, Apr 15, 2016 at 5:37 AM, George Kadianakis <desnacked(a)riseup.net> > wrote: > >> Fan Jiang <fanjiang(a)thoughtworks.com> writes: >> >> > [ text/plain ] >> > Thanks for the insights. >> > >> > >> >> >> It seems like the latest version of prop259 was posted a few weeks >> ago: >> >> >> >> >> https://lists.torproject.org/pipermail/tor-dev/2016-March/010625.html >> >> >> >> >> > <snip> >> >> > >> >> >> A few things: >> >> >> >> >> >> a) Are there still proposal design decisions that need to be taken >> and >> >> we >> >> >> are >> >> >> unclear on? I admit I'm a bit lost in the latest [tor-dev] >> thread, so >> >> >> maybe >> >> >> I can be of help somehow here? >> >> >> >> >> >> There are still some issues, like for_directory may leads to maintain >> >> two >> >> > sets of >> >> > sampled_set independently, which is not yet defined clearly in >> proposal. >> >> > >> >> >> >> Hm, how come this is happening? >> >> >> >> I would think that for_directory would now be just another filter (like >> the >> >> ipv6 one etc.) that can be applied on top of the sampled list. >> >> >> > The problem here is for_directory is a parameter of function call, that >> > means we can't do filter >> > before the call happens. Now the filter action only happens at START >> stage. >> > Maybe do a check before we return the selected guard (if not valid, then >> > continue picking new one) >> > can be a solution. >> > >> >> Hello, >> >> hm, that's an interesting problem... >> >> So we learn whether a circuit is for_directory when >> choose_random_entry_prop259() is called, but at that point the prop259 >> algorithm has already STARTed and its filtering parameters have been >> determined? >> >> So if some part of tor calls choose_random_entry_prop259() quickly twice, >> first >> with for_directory set, and the second time with for_directory unset, the >> guard >> algorithm will proceed in both cases with for_directory being set? Because >> the >> context has been set in the first call to choose_random_entry_prop259()? >> >> This seems like a problem to me, and I'm not sure how to solve it well... >> >> One way could be to use the 'cpath_build_state_t *state' in >> choose_random_entry_prop259() to be able to understand whether each call is >> about a different circuit or not. Then you could start a separate algorithm >> invocation (so new START) for each new circuit you see. >> >> But then I'm not sure how to do this without each separate algorithm call >> wrecking up the sampled_guards and used_guards lists... In the dev meeting >> in >> Valencia, we discussed with Ola and Reinaldo about using locking and >> blocking >> for this, but I'm not sure how much that would impact the performance... >> >> Do you guys have any plans here? >> >> We can have two pending_guard one for directory, one for any usage(which > will be picked by the NEXT algo, so they can be same node), > and they can be checked with directory flag before return. > Locking may not work because this algo should at least return sth before it > continues to another one, saying Dir and non-Dir are now in main loop, > Or if you have any ideas please let me know. > Hello Fan and team, I think I'm not a big fan of the pending_guard and pending_dir_guard concept. To me it seems like a quick hack that tries to address fundamental issues with our algorithm that appeared when we tried to adapt the proposal to the tor codebase. I think one of the main issues with the current algorithm structure is that _one run of the algorithm_ can be asked to _setup multiple circuits_, and each of those circuits has different requirements for guards. That is, since we do filtering on START based on the requirements of circuit #1, this means that any other circuits that appear before END is called, also have to adapt to the requirements of circuit #1. This is obvious in the code since we use guard_selection->for_directory throughout the whole algorithm run, even though for_directory was just the restriction of circuit #1. Specifically about the pending_guard trick, I feel that it interacts in unpredictable ways with other features of the algorithm. For example, consider how it interacts with the primary guards heuristic. It could be time for the algorithm to reenter the primary guards state and retry the top guards in the list, but because of the pending_guard thing we actually return the 15th guard to the circuit. IMO we should revisit the algorithm so that one run of the algorithm can accomodate multiple circuits by design and without the need for hacks. Here is an idea towards that direction: I think one very important change that we can do to simplify things is to remove the need to filter guards based on whether they are dirguards, fast, or stable. My suggestion here would be to *only* consider guards that are dirguards _and_ fast _and_ stable. This way, any circuit that appears will be happy with all the guards in our list and there is no need to do the pending_dir_guard trick. See [0] on why I think that's safe to do. This is easy to do in the current codebase. You just need to call entry_is_live() with need_uptime, need_capacity and for_directory all enabled (instead of flags being 0). If you do the above, your sampled guard set will be able to accomodate any circuit that comes its way and that should simplify logic considerably. Let me know if the above does not make sense. Here are some more comments: - So the above idea addresses a large part of the filtering logic that happens on START. The rest of the filtering logic has to do with ClientUsesIPv6, ReachableAddreses, etc. . I think it's fine to conduct that filtering on START as well. - I tried to run the branch as of bb3237d, but it segfaulted. Here is where it crashed: #1 0x000055555567eb25 in guards_update_state (next=0x5555559c3f40, next@entry=0x5555559c35e8, guards=guards@entry=0x5555559c4620, config_name=config_name@entry=0x55555570c47e "UsedGuard") at src/or/prop259.c:1137 1137 !strchr(e->chosen_by_version, ' ')) { Let me know if you need more info here. - There is a memleak on 'extended' in filter_set(). In general, I feel that logic in that function is a bit weird. The function is called filter_set() but it can actually end up adding guards to the list. Maybe it can be renamed? - What's up with the each_remaining_by_bandwidth() function name? --- [0]: I think that's OK to do and here is why: All Guards are Fast. About 95% of Guards are Stable (this will become 100% with #18624) About 80% of Guards are V2Dir/dirguards (this will become 100% with #12538) #12538 got merged in 0.2.8, so if prop259 gets merged in 0.2.9, by the time prop259 becomes active, almost all guards will be dirguards. So I think it's fine to only consider guards that are dirguards && fast && stable now, since by the time prop259 gets deployed that will be the case for almost 100% of guards.

2 7

QUIC TOR Debugging Question (no attach)
by Xiaofan Li 29 Apr '16

29 Apr '16

Hi Tim and everyone on tor-dev, Our QUIC + TOR project has almost been fully implemented. We are debugging the last few bits of bugs. Update: 1. *We've now able to build many complete circuits with QUIC as its underlying protocol. * 2. We have not debugged the actual communication part yet. We are aware of certain failure cases for QUIC (e.g. line 15642 of the log is being debugged right now). So we cannot send actually client data yet. 3. The current state uses QUIC for OR connections only. Thus a dual-path is implemented as suggested in my last email thread. 4. TLS is completely bypassed and important state (that is set up in tls_handshake functions) is preserved and refactored out. e.g. conn->/chan->state purpose, etc. 5. Some tinkering and re-designing of QUIC itself is also underway. The fact that QUIC is a transport protocol on application layer makes it painful to interact with the event and timer systems of TOR. We are trying to improve this aspect now. *The debugging log I was attaching was too big for the tor-dev list. So if you are interested to take a look at the file, let me know. Your help is greatly appreciated! * Some particularly concerning things in the log: 1. *circuit_get_by_circid_channel_impl(): found nothing for circ_id 14801, channel ID 2 (0x7f758bb6b740)* Then it just attaches this circ onto this channel.. Is this normal? 2. *Line 4901 circuit_receive_relay_cell(): Passing on unrecognized cell.* It happens a lot. Is this normal? 3. This sequence happened a lot around 7500. *relay_send_command_from_edge_(): delivering 10 cell forward. circuit_package_relay_cell(): crypting a layer of the relay cell. circuit_package_relay_cell(): crypting a layer of the relay cell. circuit_package_relay_cell(): crypting a layer of the relay cell.* It seems like its decrypting and forwarding cells along. Is it normal for TOR (with TCP) to do this in a burst? Because I'm seeing about ~1s of repeated calls. *Some more general questions:* 1. Internal Circuits: any docs? What is it used for? Measuring bandwidth? How many internal circuits are required by the system? 2. *circuit wide ID format.* We had a bug regarding this last week. The check in process_create_cell always fails because line 281-295 in *command.c* always failed (the check for CIRC_ID_TYPE and id_is_high). Currently we commented out this check. What does it affect? And could we do this? 3. From a high level, when a client sends data using a circuit, what is its code path? Which special (as in, specific to client-initiated communication) functions are called? Any other comment on the log is greatly appreciated, since everyone here is probably more familiar than me with what a normal bootstrapping process would look like. Thank you!

2 4

Tor crash debug
by Nurmi, Juha 29 Apr '16

29 Apr '16

Hi, I have been running Tor on tor2web mode[1] and now it has started to crash. See error on /log http://nzxj65x32vh2fkhk.onion/pwnzwpknl To understand the bug I re-installed Tor in Tor2web mode for debbuing: make clean && CFLAGS="-ggdb3 -O0" LDFLAGS="-ggdb3" ./configure --disab le-asciidoc --enable-tor2web-mode && make && make install And running it gdb tor (gdb) run Program received signal SIGSEGV, Segmentation fault. 0x00005555555c02d6 in rend_client_get_random_intro_impl ( entry=0x5555555bf1bf <rend_client_fetch_v2_desc+114>, strict=0, warnings=0) at src/or/rendclient.c:1353 1353 smartlist_add_all(usable_nodes, entry->parsed->intro_nodes); Any ideas what is the problem? Is there anything more I could do to debug this? [1] https://github.com/globaleaks/Tor2web/wiki/Installation-Guide Best, Juha

3 3

Onioncat and Prop224
by grarpamp 27 Apr '16

27 Apr '16

On 4/25/16, Tim Wilson-Brown - teor <teor2345(a)gmail.com> wrote: > >> On 22 Apr 2016, at 17:03, grarpamp <grarpamp(a)gmail.com> wrote: >> >> FYI: The onioncat folks are interested in collaborating >> with tor folks regarding prop224. >> >> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.t… > > I'm interested in what kind of collaboration onioncat would like to do on > prop224, next-generation hidden services. > It would be great to work this out in the next few weeks, as we're coding > parts of the proposal right now. Yep :) And I know Bernhard was hoping to get in touch with Roger on this before long. Basically, prop224 HS being wider than 80 bits will break onioncat's current HS onion <---> IPv6 addressing mechanism. They're looking at various backward compatibility options, as well as possibly making side use of the HSDir DHT, or even integrating more directly with the tor client. Onioncat v1 is here: https://www.onioncat.org/ https://www.cypherpunk.at/onioncat_trac/ https://www.cypherpunk.at/ocat/download/Docs/ list: onioncat(a)lists.blackmesa.at # 25c3: OnionCat - A Tor-based Anonymous VPN - Fischer / Haslinger https://www.youtube.com/watch?v=rx4rS1gvp7Y # Other Media https://twitter.com/search?q=onioncat https://www.youtube.com/watch?v=RFHD6rKX3LI https://elbinario.net/2014/12/02/onioncat-es-onion/ https://thehackerway.com/2011/11/14/preservando-el-anonimato-y-extendiendo-… # test a5ccbdkubbr2jlcp.onion:8060 ping6 -c 10 fd87:d87e:eb43:0744:208d:5408:63a4:ac4f 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = nnn/nnn/1nnn/1nn ms Onioncat v2 is beginning here: # OnionCat and Tor's new Cryptosystem - Fischer https://www.youtube.com/watch?v=Zj4hSx6cW80 https://itsecx.fhstp.ac.at/wp-content/uploads/2014/11/FischerOnionCat.pdf I wanted to link you out to the recent onioncat list threads on v2, but that list and its archive is down right now pending them getting it back online. I could forward the posts. Other interested people may be: # David Stainton - OnionVPN - ipv6 to onion service VPN adapter https://github.com/david415/onionvpn # Stefan Grundmann - erl_ocat - erlang onioncat implementation https://github.com/sg2342/erl_ocat # Ferdinand Haselbacher - onioncat - debian port contributed https://www.cypherpunk.at/onioncat_trac/ # intrigeri - onioncat - debian port, etc https://packages.debian.org/sid/onioncat > But the tor-onions mailing list is to discuss the technical details running > onion services. Readers of tor-onions / newbies may have been unfamiliar with onioncat. It's a way to get non-TCP between TorHS onions, thus in the thread "Hidden datagram service". I think there are a nontrivial number of users interested in, and using, non-strictly-TCP transport over an IPv6 tunnel interface. For example, look at users of CJDNS... https://www.youtube.com/results?search_query=CJDNS https://www.youtube.com/results?search_query=hyperboria For which we should try to continue a way, in v2, to do that over anonymous overlay network Tor / I2P. > Can we discuss onioncat, tor, and the development of prop224 on tor-dev > mailing list? Sounds good, especially with the onioncat list being down right now. Onioncat list had reliability issues in the past, maybe torproject would like to host it and import its ezmlm and mailman archives?

1 0

Orfox: Tor Browser for Android - GSoC 2016
by Amogh Pradeep 25 Apr '16

25 Apr '16

Hey guys, I’m amoghbl1, a 3rd year undergraduate student at International Institute of Information Technology, Hyderabad. I have been selected to work on Orfox this summer as part of Google Summer of Code. Here is my proposal if anyone wants to take a look at it: http://people.torproject.org/~amoghbl1/GSoC_2016.pdf <http://people.torproject.org/~amoghbl1/GSoC_2016.pdf> . I have tried to contribute to tor project as much as I can since 2013. I started working on Orbot late 2013 and did GSoC with tor in 2014. Since then, I have tried to involve myself with this community as much as I can. Trying to balance college work and my open source work has been difficult, but I’ve tried my best and have dedicated the past two summers to tor. In 2014, it was GSoC and in 2015, I went on to become an intern at The Guardian Project. This summer, I get to contribute again and hope to continue doing so after the summer as well. I will also be pursuing research this summer, as a visiting scholar at Katholieke Universiteit Leuven. But the best part is, I am going to do research browser fingerprinting risks for mobile browsers and Orfox. So I guess I get to enjoy the best of both worlds of research and development! Please do let me know if you have any suggestions, I’m always available on email and IRC. amoghbl1 on OFTC as well as Freenode. Best, Amogh Pradeep amoghbl1(a)gmail.com <mailto:amoghbl1@gmail.com>

1 0

Stress testing guard nodes
by Abhishek Singh 25 Apr '16

25 Apr '16

Hi, I am trying to identify bottlenecks at an entry guard when it is used to create a large number of circuits. To identify this I started a set of clients which use a single entry-guard to create 5K-10K circuits in total. With this scale clients observe timeouts (waiting for CREATED cell) while constructing circuits and they consider the entry guard to be down. I control the entry-guard chosen in this experiment and no other client should be using this relay node as a entry guard as it does not have GUARD flag in consensus. Lack of bandwidth at the entry guard is not the cause for timing-out for circuits. It consumed 80-90 KBps while the entry guard's RelayBandwidthRate is set to 400 KBps. Also, CPU at the entry-guard is not bottleneck as it was always less than 10% during the course of experiment. Can anyone provide me pointers to why these circuits timeout? And, what would be an effective way to verify that this indeed is the bottleneck? I tried profiling the entry-guard with callgrind but this is extremely slow. In the meanwhile I will create a static tor instance so that gprof produces some meaningful results. Motivation for this work is to enable a client to predict how many circuits it can create without degrading performance of its entry-guards. If a circuit is not created within a timeout period, then the client perceives the entry guard to be down and it starts using another guard node. If the client keeps on creating excessive circuits, then it is more likely to end-up using a malicious (and resourceful) entry guard. The prediction model would help the client to stay anonymous as it would refrain from unnecessarily switching guard nodes. Thanks, Abhishek

2 1

[GSOC 16] Ahmia : Hidden service search engine
by Ismael R 25 Apr '16

25 Apr '16

Hi everyone ! My name is Ismael and I'm a french student in information security. I will be working on the Ahmia search engine for this year's Google Summer of Code. Before going back to school, I was working as a "full-stack" developer for a web agency. This is why I have a little experience with the tech I will be using for this project. I'm also more free-software and privacy conscious since a couple months, that's why I'm really happy to contribute to the Tor Project. I will be working from 23 May to 21 August with my mentors Juha Nurmi (numes) and George Kadianakis (asn). I plan to send bi-weekly reports on tor-dev@. I have several major goals: Review code and infrastructure This is the part where I focus on code quality, test cases, automation and fixing bugs. I want to make existing features work better, faster, easier. Improve the search experience It all starts with indexing more information about hidden services: - Browse links on the same hidden service and treat them as different search results - Get a screenshot of the page and display it on search results - Using statistics (popularity, backlink) to give search results a score and sort them. Then, the search engine should accept commands (think duckduckgo's !bangs) or parameters (think google's site:*). Finally, (and I'm not sure I will have the time to implement this) consider using natural language processing techniques to better understand the search's query or a page's title, description or content. Statistics What should we be collecting? Can it improve search results? How can we share or visualize the data? You can read my complete project proposal on Google doc [1] or download a pdf [2]. I'm open to suggestions or questions. You can reach me by email or IRC (nick: zma). Cheers, Ismael [1] : https://goo.gl/AT37hA [2] : http://dl.free.fr/f6EMq8vOu

2 1

[GSoC16] Expand Nyx
by Sambuddha Basu 25 Apr '16

25 Apr '16

Hi everyone! I'm Sambuddha, a junior year undergraduate from IIIT-Hyderabad, India. This summer, I will be working on expanding Nyx(previously known as Arm) as a part of GSoC 2016. Nyx had its last release(1.4.5) back in 2012 and is presently under development for its next release. Some of the things that I will be working on are, getting the interpreter panel[1] back to Nyx, making use of additional relay information provided by Onionoo and expanding unit testing for Nyx. You can read my complete project proposal at [2]. My primary mentor is Damian Johnson (atagar) and my secondary mentor is Sebastian. I plan on working on the project from the first week of May till the end of July. During this time, I will be sending bi-weekly reports to this list. I'm open to any questions or suggestions and, my IRC nick is: sambuddhabasu1 Cheers! Sambuddha [1]: https://www.atagar.com/arm/images/screenshot_interpretor_full.png [2]: https://docs.google.com/document/d/12bZZq_eOMNYR8rxP4AhEgkayamLcWWul35aKgy4…

1 0

Tor Browser Bundle on musl libc systems
by Daniel Simon 25 Apr '16

25 Apr '16

Hi, the Tor Browser Bundle binaries available at https://dist.torproject.org/torbrowser/5.5.4/ do not run on musl-libc-based systems, like Void Linux, Alpine Linux, and other Linux distributions. I believe that's the case because the Tor Browser Bundle binaries are compiled dynamically to glibc, making them fail when ran on systems that any other libc. I'm sending this message to the Tor mailing list and to the Musl mailing list, so we can together find a solution. I think there are 4 possible solutions: - the tor developers can provide binaries built with musl libc - the tor developers can provided statically compiled binaries (with any libc, but musl is especially good for this). These statically compiled binaries would run on any system independently of the libc. - the musl libc developers could identify why the binaries fail on musl and try to add compatibility - Linux distributions that use musl libc could figure out how to compile the Tor Browser Bundle from source and provide binaries themselves What does everyone think about these possible solutions? Which one is the best? Are there any others you can think about? Thanks for everyone's time, D. Simon

1 0