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

Piloting a new contributor workflow on gitlab.torproject.org
by Micah Anderson 06 Aug '25

06 Aug '25

Hi all, If you've recently tried to fork a Tor repository into your personal gitlab.torproject.org namespace and received an error, you’re not alone. This is a known limitation of our current GitLab setup. To address this, we are piloting a new contributor workflow designed to make it easier for community contributors like you to propose changes, open merge requests, and collaborate, without needing write access to Tor’s canonical GitLab repositories. We’ve created a shared GitLab group for contributor forks called tor-contributors[0]. This group hosts mirrored forks of selected Tor projects. When you want to contribute, you can request access to the relevant contributor fork, create a branch (e.g., username/fix-x), and open a merge request back to the canonical repository. We’re looking for contributors who are actively working on changes and would like to participate in this pilot by trying out the workflow and providing feedback. If that’s you, please follow the onboarding instructions[1]. To help keep things manageable, we ask that people only request access if they are preparing to open a merge request. If you're just curious or want to follow along, there is no need to request access, we will continue to share updates as the pilot evolves. Thanks, and we look forward to your feedback. Thanks, Micah 0. https://gitlab.torproject.org/tor-contributors/ 1. https://gitlab.torproject.org/tor-contributors/meta -- Micah Anderson (he/him) Director of Engineering The Tor Project, Inc. <https://torproject.org>

1 0

Available implementation and report on quantum-safe fully encrypted protocols
by Marc Himmelberger 04 Aug '25

04 Aug '25

Hi, I have just concluded my Master's Thesis at ETH Zurich titled "Implementing and Evaluating Quantum-Safe Fully Encrypted Protocols" and I believe the content is relevant for this mailing list. My thesis consists mainly of the implementation of the "Drivel" protocol [1]. Two of the authors of [1], Felix Günther (mail(a)felixguenther.info) and Shannon Veitch (shannon.veitch(a)inf.ethz.ch) supervised this thesis and are also available for questions regarding the protocol design in this thread. Drivel is an evolution of obfs4 [2] that: - allows for key encapsulation mechanisms, particularly the ones proposed as part of the NIST standardization [3], - has stronger obfuscation, providing more guarantees than obfs4 in the scenario that censors should get ahold of bridge information such as NodeID and long-term public key, - contains a thin crypto-agility layer, allowing the replacement of cryptographic algorithms as needed, - provides more configuration options to bridge operators regarding performance trade-offs by allowing for runtime-configuration of the cryptographic algorithms, and - allows for post-quantum traditional hybrid instantiations. Note:; my thesis covers the “pure” post-quantum case (i.e., non-hybrid). Due to the crypto agility, hybrids are relatively easy to add by implementing an appropriate PQ/T hybrid combiner, such as OEINC [1]. Additionally, there are proposed changes to Drivel itself, evaluations of the implementation's performance, and some security proofs in the thesis. The main purpose of my proposed changes is to add more flexibility in traffic shaping (minimize “quiet periods” previously discussed on this list [4]) and to optimize performance. The thesis PDF is available under: https://doi.org/10.3929/ethz-b-000746588 The chapters "Implementing Drivel" and "Experimental Evaluation" should be most relevant to this list. I encourage everyone interested in pluggable transports to have a look if this sounds intriguing. The implementation is done as a fork of the lyrebird repository [5] and is available under: https://github.com/marc-himmelberger/lyrebird-drivel The Tor Project is more than welcome to use my work for future changes to lyrebird, although I do believe some changes to drivel and some optimizations to my code may be beneficial for performance reasons before the pluggable transport is used in production. In case of any feedback or questions, do not hesitate to reach out. Best regards, Marc Himmelberger [1] https://eprint.iacr.org/2025/408.pdf [2] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyre… [3] https://csrc.nist.gov/projects/post-quantum-cryptography [4] https://archive.torproject.org/websites/lists.torproject.org/pipermail/tor-… [5] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyre…

2 1

meek-azure to meek rename
by Morgan 04 Aug '25

04 Aug '25

Hi everyone, We are going to be renaming the 'meek-azure' built-in bridge type to 'meek' in Tor Browser Alpha 15.0aX and and some of the surrounding ecosystem in the relatively near future. For background, see this issue: - https://gitlab.torproject.org/tpo/applications/team/-/issues/37 This will affect you *sooner* (i.e. in the coming month or two) if you: - consume pt_config.json: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/mai… - If you populate your own application's built-in bridges from this file you may need to implement settings migration logic, in-app string updates, etc; in the future the 'meek-azure' key on the 'bridges' object will be just 'meek' - use the name 'meek-azure' or reference Azure in your app; the built-in 'meek-azure' bridges don't actually run on Azure anymore so if your app references Azure or Microsoft, you should probably update your copy - See this issue for updating Tor Browser's strings for reference: - https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44069 This will affect you *later* (i.e. in the coming several months to a year) if you consume: - rdsys censorship circumvention APIs to query bridges by 'builtin' type - the high-level plan is to add meek-azure -> meek shims on the server-side so any legacy clients will still work into the future (though at some point such shims will surely be dropped) - new callers should instead request 'meek' bridges rather than 'meek-azure' - issue is being tracked here: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/272 One thing to note is that this dose not affect the actual bridge-lines or pluggable-transport client configuration lines which are given to tor. The underlying pluggable-transport is still 'meek_lite', the rename only really affects the user-visible 'meek-azure' name. Please let me know if you've any questions/concerns! best, -morgan

1 0