January 2022 - tor-dev - lists.torproject.org

Interoperation with libp2p
by Mike Mestnik 07 Apr '22

07 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

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

Relay "Ping" Functionality
by Alexander Mages 20 Feb '22

20 Feb '22

Hello Tor-Dev, My name is Alex Mages, and I have been doing pluggable transport research with Eugene Vasserman (CC) at Kansas State University. Right now we're exploring latency-based attacks but are having trouble achieving a particular goal: a way to “ping” an arbitrary node in a client’s already-built (“live”) circuit. One-way timing is ideal but round trip time would suffice. We can glean this information during circuit construction, but what about a “live” circuit? Ideally, this would be a periodic thing Tor already keeps track of, but as an on-demand or as a byproduct/side-effect of a different function would also work. We have not been able to find a way to do this within the Tor (sub)protocol specs or the control port spec. Any ideas, suggestions, or criticisms would be greatly appreciated. Thanks, Alex Mages

3 4

onionoo overload_general_timestamp (prop 328)
by nusenu 11 Feb '22

11 Feb '22

Hi, in onionoo all timestamps used to be in the format YYYY-MM-DD hh:mm:ss Proposal 328 has timestamps in this same format https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/328-re… The newly added prop328 fields in oninoo appear to break with that convention https://metrics.torproject.org/onionoo.html#details_relay_overload_general_… Here is an example for an onionoo overload_general_timestamp which appears to be at millisecond granularity (the source has a granularity of an hour): 1636038000000 Was there a particular motivation for this format change and granularity? And what do you think about changing it to use the YYYY-MM-DD hh:mm:ss format for consistency and having a direct human readable format here as well? related: Karsten used to maintain onionoo protocol documentation/changelog and versions: https://metrics.torproject.org/onionoo.html#versions Is that and the 'version' field in onionoo no longer maintained? (since it didn't change with the new fields) kind regards, nusenu -- https://nusenu.github.io

2 3