- tor-dev - lists.torproject.org

How to get source port from conn object
by redriderbbgun11 01 May '22

01 May '22

Hey all, I want to get to know the TOR codebase so I can contribute to the project. To do this I have been doing a few projects of just doing sort of basic tasks to get an idea for how it all works together. One thing that is giving me a bit of trouble but seems like it should be simple is finding the source port for a conn object. How do I find this and moreover how do I find the actual socket behind a given connection? In connection_t I see tor_socket_t but it seems to just be an int value. Thanks

1 0

Discussion about Tor Directory Authority Consensus Code
by Zhongtang Luo 26 Apr '22

26 Apr '22

Hi all! I am a PhD student currently doing some experiments on Tor. My advisor and I was wondering if we can talk to somebody who takes care of the Tor Directory Authority code, since there is a conceptual issue we wish to communicate with them. Can somebody direct us to the appropriate person? Many thanks. Yours, Zhongtang Luo

2 1

We built a new Tor-based team chat prototype. Wanna try it?
by Holmes Wilson 15 Apr '22

15 Apr '22

Hi everyone, My collaborators and I have been working for the past couple years on building a Tor-based team chat app which we're calling Quiet*, and I'm curious if anyone here would like to try it out! If you would, please reply! :) I am especially interested in feedback from Tor project participants and people who are sometimes in the position of advising organizations on their security needs, but everyone on this list is welcome! What I'll try to do is find a time that would work for all of us so we can try it together in a true test of its team chat possibilities, though if that doesn't work I'm happy to do one on one meetings too. Quiet is still lacking pretty much every feature imaginable except adding team members and sending and receiving messages. And mobile apps aren't ready yet. And it hasn't been audited so it shouldn't be used for anything important at all. And so on. But if you've tried any attempts at p2p group chat before, this one will strike you as surprisingly reliable thanks in no small part to the reliability of Tor. So it's pretty cool to see it in action and it's a fun new way to use Tor. Again, I'm not looking for any real end users at this stage—we're just not ready for that yet. But we've invested a lot in usability and reliability and we're making a really serious go of it. This isn't vaporware and I think it'll be worth your time to check it out! :) Perhaps the coolest part about our approach is that its usefulness goes way beyond chat apps. The approach we've taken is adequate for building private, F/OSS alternatives to a large class of crucial applications that currently lack strong privacy and security properties, such as Trello, Asana, Basecamp, Google Docs and Sheets, Figma, Discourse, Airtable, team password managers, and more. Specifically, you can use it to build any application where a bounded group of people share some common workspace, as long as the data would fit on a typical consumer device. And perhaps from that foothold we can figure out ways to extend the model to be adequate for building large unbounded networks like Signal, Twitter, and Facebook in a decentralized way, though that's a much harder class of problem. (I gave this talk <https://archive.org/details/hopeconf2020/20200802_1600_Zbay%2C_Fighting_FAA…> a couple years back at HOPE 2020 about these ideas which is a pretty good overview of the motivations behind the project, and and I'll be speaking again at HOPE 2022 this summer about where we're at now, so it would be great to meet up there if anyone else will be there!) I've included some more notes below on how it works for those who are curious. But if you're curious please write me back so I can give you a demo :) Holmes # How it works Quiet is like a combination of Slack and Ricochet. Ricochet did not depend on any servers except for the Tor network itself, and sent messages directly over onion services, but it was only for 1:1 messaging. Like Ricochet, Quiet doesn't require any servers except for the Tor network itself, but it uses some p2p libraries that have emerged over the past few years to enable group chat where—like Slack and Discord—all clients tend to display the same message history, even clients that were offline when messages were sent. Specifically, Quiet uses OrbitDB, a CRDT. CRDTs are sort of like Git, where they enable syncing between decentralized peers such that all peers eventually converge on the same state. OrbitDB is built on IPFS, so unlike a lot of CRDTs (like Automerge) it comes with some built-in ability to move data around between peers. IPFS is pretty flexible and we set it up so that each team has its own totally isolated IPFS network, and all the IPFS clients connect to each other over Tor. There's no big, global, leaky p2p network, and no blockchain or anything like that. You have a group of friends, and you just talk to each others onions. That's it. To invite a new user, an authorized user shares an onion service link to a "registrar" onion service running on their machine, and they add that new user's key information to a user table, and give the user a certificate they can use to connect to other peers. A single community owner uses certificates to grant unique usernames. Mobile apps use the same approach, though we'll need a centralized service for notifications on iOS until someone changes the way Apple Apples, and we haven't built that yet. There are a lot of other important pieces of the design we haven't tackled yet too, such as timed message deletion, removing users, use of onion auth for incoming connections, optimizations for very large communities, and so on. But it's all fairly tractable, if a bit slow going. (I'm also really interested if this description is clear and would love your feedback and questions!)

1 0

Interoperation with libp2p
by Mike Mestnik 06 Apr '22

06 Apr '22

https://gitlab.torproject.org/tpo/core/torspec/-/issues/64

5 5

[dappy] Willing to chat with tor devs, about name system issues/solutions
by Raphaël Fabre 27 Mar '22

27 Mar '22

Hello I'm Raphaël (fr) I just joined the tor dev mailing list. I would like to chat with tor developers, particularly if they have worked, or are interested in the issues regarding a name system for tor. I'm the lead developer of dappy https://dappy.tech , we'll launch in 2022 and I do think we have interesting properties, for the public web as well as for tor and privacy-focused web projects. We are the only name system in the world that does co-resolution, that's the way we found to maintain a consistent name system, and also avoid censorship and phishing. Our system has the following properties: - blockchain-based name system: it simply means that mapping is globally consistent, name management is distributed in the sense that a blockchain handles it, the resolver just connect to this blockchain. - Systematic co-resolution (not rotation): lookup request are always addressed to a network of independant agents: there are many instead of a single one. And then there is consensus at browser level. This prevents 90% of attacks or attempt of censorship/phishing. - Anonymous registrations - Load-balancing of names: you can attach 20 IP addresses to your name, dappy browser will try each one of them until it gets a response. - 100% encrypted/https Censorship cannot happen, neither at the storage location (blockchain) or on-the-fly at resolution time (co-resolution) We will launch in 2022 and would be thrilled to exchange with some developers or engineers. This document has lead me to the path of the tor-dev mailing list https://gitlab.torproject.org/legacy/trac/-/wikis/doc/OnionServiceNamingSys… Happy to chat Merry Christmas Raphaël Fabre Building a ultra-secure blockchain-based name system and browser https://dappy.tech

2 2

Time interval for changing Introduction Points in Tor Hidden Services
by Piyush Kumar Sharma 23 Mar '22

23 Mar '22

Hi all, I have been investigating the Tor hidden services for some research work. I am finding it hard to obtain information about how often do Introduction Points of hidden service change. More specifically, I am looking for answers to the following questions: 1.) If the tor relays selected as Introduction Points for a hidden service go down (e.g., due to DoS), then in what time duration does the hidden service select new Introduction Points automatically? 2.) Even when the Introduction Points are not down, is there a duration after which they are automatically changed by the hidden service? If so, what is this duration? I have already tried to find this information in the Tor-spec about onion v3 services. But could not find answers to these specific questions. Thus, it would be really helpful if someone can answer these questions or point to some resources where this information can be obtained. Thanks

2 3

Gosling onion-to-onion specifications
by Richard Pospesel 19 Mar '22

19 Mar '22

Hi tor-dev, As part of my work with Blueprint for Free Speech, I recently gave a short presentation during the 2021 state-of-the-onion where we announced Gosling ( see https://youtu.be/mNhIjtXuVzk?t=8155 ). If you missed the talk, the tldr; is that we're developing a specification and reference implementation library for building (onion service based) anonymous+private+secure peer-to-peer applications. Essentially, we're taking what we've learned about onion-to-onion authentication from Ricochet-Refresh, extracting and improving the relevant pieces, and packaging it all in a library that developers can use to build their own anonymous+private+secure peer-to-peer applications. Our hope is that future developers will not need to be tor experts to build these types of applications. Today ,I'm happy to announce that we just made the the gosling repo on Github public! - https://github.com/blueprint-freespeech/gosling Things are little bare-bones at the moment, but the most relevant piece right now is the protocol specification here: - https://github.com/blueprint-freespeech/gosling/blob/main/docs/protocol.md You'll also find some initial prototyping work under the source directory (the pace of development should pick up come 2022). Please go take a look and feel free to respond here with any questions, concerns, criticisms, etc. Thanks! best, -Richard

1 1

txtorcon v22.0.0
by meejah 16 Mar '22

16 Mar '22

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I'm pleased to announce txtorcon 22.0.0. This fixes some broken infrastructure. * Use GitHub Actions (not Travis) * Update method to upload coverage to coveralls You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/22.0.0 https://github.com/meejah/txtorcon/releases/tag/v22.0.0 Releases are also available from the hidden service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check 89a1b65e32a4b369d67e6c166387fbc468cc5d05227448d239a5e7e9718aa053 dist/txtorcon-22.0.0.tar.gz 824b5df1977bedabfc1c49c9523b8fa1b7cff11d6fee78015df1ce133685779c dist/txtorcon-22.0.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCgAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAmIyVzMRHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaaeNYQf/XBYfAvqqvT/jU+z8EUwgj0EJbFusNAls 8W37RE8fRkxTCYBOnfmK2IlQouHLBVgjzS2H0ZGyAzczxZb/kfY7uRbAm7N63eMx rc7urZtDeHS4K7+cUPf03KlqYdKmbIGEezPVQSNRT1/UZ/kTB6CxMqteyXxfYkvY +pkfIvOJ49Yw6KuMt+iWKRNnfVsMNYX+gV6PNYBHoWGRTWxANReaXRSowe+5Cgus 4O51I3+1QH1slLIH77Dvpktmqka+Fbs3mDWm1ICzf4rB0z+aJRxt7xYjNnhaLCPQ 5xeY1IdmmJAxg/WouMQh1Kus8eEWgIhFLeigPN+ABwt2VziL1lL8XQ== =HKmX -----END PGP SIGNATURE-----

1 0

Proposal 338: Use an 8-byte handshake in NETINFO cells
by Nick Mathewson 14 Mar '22

14 Mar '22

``` Filename: 338-netinfo-y2038.md Title: Use an 8-byte timestamp in NETINFO cells Author: Nick Mathewson Created: 2022-03-14 Status: Open ``` # Introduction Currently Tor relays use a 4-byte timestamp (in seconds since the Unix epoch) in their NETINFO cells. Notoriously, such a timestamp will overflow on 19 January 2038. Let's get ahead of the problem and squash this issue now, by expanding the timestamp to 8 bytes. (8 bytes worth of seconds will be long enough to outlast the Earth's sun.) # Proposed change I propose adding a new link protocol version. (The next one in sequence, as of this writing, is version 6.) I propose that we change the text of tor-spec section 4.5 from: ``` TIME (Timestamp) [4 bytes] ``` to ``` TIME (Timestamp) [4 or 8 bytes *] ``` and specify that this field is 4 bytes wide on link protocols 1-5, but 8 bytes wide on link protocols 6 and beyond. # Rejected alternatives Our protocol specifies that parties MUST ignore extra data at the end of cells. Therefore we _could_ add additional data at the end of the NETINFO cell, and use that to store the high 4 bytes of the timestamp without having to increase the link protocol version number. I propose that we don't do that: it's ugly. As another alternative, we could declare that parties must interpret the timestamp such that its high 4 bytes place it as close as possible to their current time. I'm rejecting this kludge because it would give confusing results in the too-common case where clients have their clocks mis-set to Jan 1, 1970. # Impacts on our implementations Arti won't be able to implement this change until it supports connection padding (as required by link protocol 5), which is currently planned for the next Arti milestone (1.0.0, scheduled for this fall). If we think that that's a problem, or if we want to have support for implementations without connection padding in the future, we should reconsider this plan so that connection padding support is independent from 8-byte timestamps. # Other timestamps in Tor I've done a cursory search of our protocols to see if we have any other instances of the Y2038 problem. There is a 4-byte timestamp in `cert-spec`, but that one is an unsigned integer counting _hours_ since the Unix epoch, which will keep it from wrapping around till 478756 C.E. (The rollover date of "10136 CE" reported in `cert-spec` is wrong, and seems to be based on the misapprehension that the counter is in *minutes*.) The v2 onion service protocol has 4-byte timestamps, but it is thoroughly deprecated and unsupported. I couldn't find any other 4-byte timestamps, but that is no guarantee: others should look for them too.

2 3

Fine Tunneling For Tor Network | Tor Browser
by Alessandro Greco 09 Mar '22

09 Mar '22

Dear Tor-Dev, My name is Alessandro Greco and I am an Italian computer science student, I am finishing my studies and therefore I am working with my thesis and, as a topic, my supervisor and I have chosen the Tor network. The work done focuses entirely on the Tor Browser torrc configuration file, which is why I wrote Professor Steven Murdoch and he pointed me to this method in order to get in touch with the current Tor-Project developers. I state that I am not good in English and therefore I may be wrong or not give the right weight to the words. Going into the matter, I have developed an extension currently available only on Firefox reachable via the addresshttps://addons.mozilla.org/it/firefox/addon/tropea-project/. The initial goal was to simplify the tunneling phase, already editable through the Tor Browser torrc file, through commands such as ExitNode or ExcludeNode and much more. In order to simplify the use, I decided to create an extension and an "advanced" section, thus bringing back user-friendly graphic interfaces already well known to average users (the advanced section consists of a web page), which would allow modify the file to your liking without necessarily having to follow correct syntax and without having to go too far into the technical aspect of Tor Browser. Why? I decided to simplify the use of this configuration file because I believe that the path of "simplification" is the only (or in general one of the most important) way to be able to expand the catchment area by trying to accommodate more people who have the need for a network like Tor in order to be able to divert dictatorial censorship methods by governments. I want to give a practical example, let's consider the current situation between Russia and Ukraine. Although Putin belongs to Russia, it is also true that there is a large slice of Russian citizens who are intellectually suppressed every day given the limits of censorship by the Russian government and by other governments that limit the people in order to weaken Putin. Russia has currently blocked several social networks so that citizens can no longer share the atrocities that are happening, so much so that Anonymous has asked to publish photos and videos of what is happening through Google Maps or other applications that are currently not censored. In all this mess, I sincerely think that Tor can significantly affect the protection of truth and rights on the net. But it is also true that many people do not know how to use or modify these settings correctly or, more simply, they may not even know that they can change some settings. I strongly believe that a breakthrough in the world of Tor Networks is needed and so that citizens of every state in the world can have, without minimum IT requirements, the ability to fully use Tor Browser and consequently Tor. The thesis work is called Tropea-Project (Tropea is a type of onion from our area, if you want to do a search, look for Tropea Onion on Google) and it is completely free and open-source so that anyone can dare to add new features. The features currently available are the following: [Add-Remove] EntryNodes + StrictNodes [Add-Remove] ExitNodes + StrictNodes [Add-Remove] ExcludeNodes [Add-Remove] ExcludeExitNodes [Edit] GeoIPExcludeUnknow [Edit] Reset configuration [Torify App] Torify /*It depends on the application launched, [Working Application](https://github.com/NoNameoN-A/Tropea-Project/blob/main)*/ Please consider this project, at the moment I am struggling with the writing of the thesis so in a few weeks an extremely detailed guide on the whole programming aspect will be published so that I can help any student, programmer, hacker and anyone who wants to improve existing features or add new ones. I am very excited to write you this email and I hope you can consider this development of mine which focuses 100% of the forces so that the Tor project can help free as many people as possible from inhuman web slavery. I believe that online freedom is a humanitarian right on par with education and water, so I think it is appropriate to develop new features that simplify its use. If you have read this far I would ask you now to see the demonstration video that I have published so that you can see for yourself what it does and I hope you can understand how much I care. Now more than ever anyone needs Tor. * Technical notes on the extension * In order for it to be used correctly, you must first start a local script called tropea.js, which is located in the socket-tropea folder of the Repository. The extension code is in the tropea folder of the Repository. Since the exact path of the Tor Browser folder is required, due to the configuration of the torrc file, it would be ideal to install it when installing Tor Browser so as to further simplify the whole process so that they don't even have to run the local script as it might launch when Tor Browser starts. Repository:https://github.com/NoNameoN-A/Tropea-Project Demonstration video:https://peertube.uno/w/acz9VzntwYFicwgxk7i9by I wrote an informal article on my blog:https://greco-alessandro.netlify.app/articles/tropea-project-la-rete-tor-da-un-altro-punto-di-vista/ Thesis with technical documentation of the code: At the moment not available because I haven't finished writing it yet. Best Regards, Alessandro Greco. -- FSF Member (NoNameoN), Join the Free Software Foundation! (fsf.org) Browse my WebSite! (autistici.org/nonameon)

1 0