- tor-dev - lists.torproject.org

[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

Proposal 358: Unifying circuit handshake extensions
by Nick Mathewson 27 Mar '25

27 Mar '25

https://spec.torproject.org/proposals/358-unified-handshake-extensions.html This proposal suggests that we should unify the EXT_FIELD_TYPE namespace, which is currently shared between CREATE2 and INTRODUCE2 messages. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick

1 0

Proposal 357: Circuit key exporters: A better way to use KH
by Nick Mathewson 27 Mar '25

27 Mar '25

https://spec.torproject.org/proposals/357-circ-key-exporters.html This proposal declares a new way to use the "KH" output of our circuit handshake protocol in the future, to avoid the possibility of creating cross-protocol attacks. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick

1 0

Proposal 356: Increasing netdoc strictness not considered (very) harmful
by Nick Mathewson 27 Mar '25

27 Mar '25

https://spec.torproject.org/proposals/356-desc-parsing-variance.html This proposal explains why we will not, in the future, generally worry about protocol changes that make strings that were formerly accepted as network documents become rejected in future versions. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick

1 0

Proposal 355: Options for postquantum circuit extension handshakes
by Nick Mathewson 27 Mar '25

27 Mar '25

https://spec.torproject.org/proposals/355-revisiting-pq.html This proposal updates earlier proposals about postquantum cryptography in Tor circuit extensions, to handle changes in Tor and the PQ landscape since those proposals were written. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick

1 0

Make torsocks mutli-arch ready
by Hefee 27 Mar '25

27 Mar '25

Hey, in Debian we want to enable mutli-arch support for torsocks. To be able to run different binaries of different archs. We already splitted libtorsocks into own package, so you can now install e.g.: torsocks:amd64, libtorsocks:amd64, libtorsocks:i386, wget:i386 But the torsocks script loads the libtorsocks by full path, so torsocks wget will fail, as it loads the amd64 variant only. ldconfig has this nice feature to find the correct library, if you only add the name and that the library is in default search dir or you add a conf file in / etc/ld.so.conf.d/. Using just the libname makes the "safty" check `! -e "$SHLIB"` fail, as $SHLIB, is only the libname in our case. Can you have a look at the patch[1], if you think it is safe to ship this? [1] https://salsa.debian.org/pkg-privacy-team/torsocks/-/blob/master/debian/ patches/0004-Make-torsocks-multi-arch-foreign-compatible.patch The issue I see is this: If arch from executable and the corresponding libtorsocks is not installed, only a Error is printed, but still the executable is executed without routing trough tor. The disabled check in torsocks could somehow catch this, if we would knew the arch of the executable in advanced correctly (which we don't, so far). If we can make sure, that LD_PRELOAD would stop executing, if the library cannot be found. e.g. I install libtorsocks:amd64 and wget:i386 I get: $wget -O- -4 icanhazip.com XX.230.187.XX $ torsocks wget -O- -4 icanhazip.com ERROR: ld.so: object 'libtorsocks.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. [...] XX.230.187.XX [...] (installing libtorsocks:i386 fixes this) On the other side, this does not got worse; currently torsocks will print a different error see #902792 but still execute the binary without tor. So this safety check doesn't help here (and btw. installing libtorsocks:i386 does not fix this issue by itself you also need to call /usr/bin/i386-linux-gnu- torsocks). #902792 https://bugs.debian.org/cgi-bin/902792 Regards, hefee

2 4