April 2025 - tor-dev - lists.torproject.org

What happens to my hidden service?
by Liste 29 Dec '25

29 Dec '25

Hidden service is unavailable, but tor is running. Tor's log: Dec 12 18:10:27.000 [notice] Your Guard SECxFreeBSD64 ($D7DB8E82604F806766FC3F80213CF719A0481D0B) is failing more circuits than usual. Most likely this means the Tor network is overloaded. Success counts are 199/285. Use counts are 101/101. 253 circuits completed, 0 were unusable, 54 collapsed, and 15 timed out. For reference, your timeout cutoff is 60 seconds. is failing a very large amount of circuits. Most likely this means the Tor network is overloaded, but it could also mean an attack against you or potentially the guard itself. Dec 12 18:15:53.000 [warn] Giving up launching first hop of circuit to rendezvous point [scrubbed] for service xxxxxxxxxxxxxxx. Dec 11 13:08:59.000 [notice] We'd like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits pending. Waiting until some finish. [268 similar message(s) suppressed in last 600 seconds] Dec 11 13:43:12.000 [warn] onion_skin_client_handshake failed. Dec 11 13:43:12.000 [warn] circuit_finish_handshake failed. Dec 11 13:43:12.000 [warn] connection_edge_process_relay_cell (at origin) failed. Dec 11 00:34:57.000 [warn] Giving up launching first hop of circuit to rendezvous point [scrubbed] for service .... Dec 10 10:09:01.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 10:09:03.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 10:09:04.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 12:42:19.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t.

3 2

[GSoC 2025] Graph-Based Relay Partitioning – Proposal and Repository
by Valentina Schiavon 21 Apr '25

21 Apr '25

Dear Tor team, I recently submitted a proposal to Google Summer of Code 2025 titled "Graph-Based Analysis of Relay Partitioning in the Tor Network", focused on detecting partitioning patterns through graph data science techniques. Although the project is still in its proposal phase, I have already created a GitHub repository( https://github.com/valentinaschiavon99/tor-relay-partitioning-gsoc2025) where I’m documenting the structure, early diagrams, and test notebooks. I'm reaching out in case any of you have suggestions or would like to point me toward related work, potential pitfalls, or early contributions I could start working on (e.g., documentation or testing). Thank you very much for your time and for the opportunity to contribute to such an impactful project. Best regards, Valentina Schiavon Business Informatics student @ AAU Klagenfurt ,Austria https://www.linkedin.com/in/valentinaschiavon1/ https://github.com/valentinaschiavon99 valentinaschiavon99(a)gmail.com

1 0

Proposal 360: Limiting HSDesc size and amplification
by Nick Mathewson 09 Apr '25

09 Apr '25

https://spec.torproject.org/proposals/360-hsdesc-len-limit.html This proposal describes a mechanism for preventing some kinds of traffic-flooding attacks by HSDirs. It's based on some of Mike Perry's work on Proposal 349. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! best wishes, -- Nick

1 0

Proposal 359: Counter Galois Onion, Updated
by Nick Mathewson 09 Apr '25

09 Apr '25

https://spec.torproject.org/proposals/359-cgo-redux.html This proposal instantiates a new approach for encrypting relay cells on circuits, to prevent certain kinds of tagging attacks, to improve forward secrecy, and more. It is based on research by Jean Paul Degabriele, Alessandro Melloni, Jean-Pierre Münch, and Martijn Stam. You can read their paper at https://eprint.iacr.org/2025/583 This is important and subtle; I'd appreciate any feedback, especially from cryptographers. I plan to start implementing this quite soon, on the theory that, even if there _are_ flaws, it is very unlikely to be _worse_ than our current malleable relay encryption. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick

1 0

can tor use secondary groups to read FamilyKeyDirectory?
by nusenu 09 Apr '25

09 Apr '25

Hi, given the following example, tor fails to access the familykeydir folder. familykeydir has the following permissions: drwxr-x--- 2 root tor_reader id _tor uid=996(_tor) gid=993(_tor) groups=993(_tor),994(tor_reader) Is tor able to use secondary groups? When using sudo to switch to user _tor manually, it is possible to read files in that folder without problems. The problem does not happen when _tor's primary group is set to 'tor_reader'. Tested on debian. kind regards, nusenu -- https://nusenu.github.io

3 3

Call for comments on proposals 346, 354, and 358.
by Nick Mathewson 08 Apr '25

08 Apr '25

Hi, all! We're hoping to implement these proposals soon: https://spec.torproject.org/proposals/346-protovers-again.html https://spec.torproject.org/proposals/354-relaxed-restrictions.html https://spec.torproject.org/proposals/358-unified-handshake-extensions.html Barring major objections, we're going to change their state from "Open" to "Accepted" in about a week. If anybody would like to comment, either here or on the bugtracker (https://gitlab.torproject.org/tpo/core/torspec/) that would be great! best wishes, -- Nick

1 0