[tor-dev] Proposal 363: Required/recommended protocols for onion services

https://spec.torproject.org/proposals/363-required-protovers-and-hs.html This proposal describes an enhancement to how we use subprotocol versioning in the consensus to advertise recommended and required subprotocols for running and connecting to onion services. Please feel free to open tickets o

[tor-dev] Proposal 364: CreateOnehop handshake to replace CREATE_FAST

https://spec.torproject.org/proposals/364-create-onehop.html This proposal describes a successor to CREATE_FAST that permits circuit handshake extensions. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! -- Nick __

[tor-dev] Proposal 360: Limiting HSDesc size and amplification

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

[tor-dev] Proposal 359: Counter Galois Onion, Updated

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-P

[tor-dev] Call for comments on proposals 346, 354, and 358.

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

[tor-dev] Re: can tor use secondary groups to read FamilyKeyDirectory?

On Thu, Apr 3, 2025 at 6:29 PM nusenu via tor-dev wrote: > > 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)

[tor-dev] Proposal 358: Unifying circuit handshake extensions

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 th

[tor-dev] Proposal 356: Increasing netdoc strictness not considered (very) harmful

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 ticket

[tor-dev] Proposal 355: Options for postquantum circuit extension handshakes

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 discus

[tor-dev] Proposal 357: Circuit key exporters: A better way to use KH

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. D