Tor Specifications issueshttps://gitlab.torproject.org/tpo/core/torspec/-/issues2022-05-23T20:29:49Zhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/98Write proposal for RELAY_AUTHENTICATE/multipath AUTHENTICATE delivery2022-05-23T20:29:49ZMike PerryWrite proposal for RELAY_AUTHENTICATE/multipath AUTHENTICATE deliveryTo protect against relay key theft, it would be useful if relays supported a way to replay the ntor handshake and the DH/ECDH TLS handshake via a directory mirror whose keys are stored in the Tor source code (via legacy/trac#572).
The i...To protect against relay key theft, it would be useful if relays supported a way to replay the ntor handshake and the DH/ECDH TLS handshake via a directory mirror whose keys are stored in the Tor source code (via legacy/trac#572).
The idea is that clients could replay some percentage of their circuits' and TLS connections handshakes via independently authenticated cryptographic paths using the directory mirror keys and legacy/trac#5968. If any one handshake replay failed to yield the same session keys from a replayed DH/ECDH/ntor handshake for any subset of the paths, we know the authentication key for that handshake was stolen and one of the client's paths was MITMed, and we could sound the alarm bells.
We'd probably need two cell types for this: a VERIFY cell that included enough information to replay one or both handshakes, and a RELAY_VERIFY cell that instructed a relay to send an enclosed VERIFY cell on behalf of a remote client.
It would be extra neat if we could use this mechanism as the basis for a proper TLS extension, to allow the whole web to do stuff like this.https://gitlab.torproject.org/tpo/core/torspec/-/issues/85Write "how to be nice to the Tor network" spec2022-04-25T20:52:29ZRoger DingledineWrite "how to be nice to the Tor network" specIn talking to Jake, I realized that there are still some people who expect jtor to be a workable Tor client one day. In fact, we've even been writing some funding proposals that make this assumption.
One of the main issues we're going t...In talking to Jake, I realized that there are still some people who expect jtor to be a workable Tor client one day. In fact, we've even been writing some funding proposals that make this assumption.
One of the main issues we're going to have with an alternate Tor client is that while it may follow our network specs, it will have different observable behavior than the mainline Tor client.
First, this different behavior will make users partitionable. Fine, we can accept that. But we should finish writing path-spec.txt so authors of other clients can have at least a chance of doing things the way "real" Tor does.
Second, it's easy to make client-side decisions that harm the Tor network. For examples, you can hold your TLS connections open too long, or do too many TLS connections, or make circuits too often, or ask the directory authorities for everything. We need to write up a spec to clarify how well-behaving Tor clients should do things. Maybe that means we write up some principles along the way, or maybe we just identify every design point that matters and say what to do for each of them.https://gitlab.torproject.org/tpo/core/torspec/-/issues/53find all instances of SHA-1 in our design and implementation and kill them wi...2023-11-06T13:53:08ZIsis Lovecruftfind all instances of SHA-1 in our design and implementation and kill them with fireThis is a parent ticket for finding every use of SHA-1 in our specs/design and code, detailing it, and coming up with a plan to replace it.
From [the Seattle notes](https://trac.torproject.org/projects/tor/wiki/org/meetings/2018NetworkT...This is a parent ticket for finding every use of SHA-1 in our specs/design and code, detailing it, and coming up with a plan to replace it.
From [the Seattle notes](https://trac.torproject.org/projects/tor/wiki/org/meetings/2018NetworkTeamHackfestSeattle/OldCrypto), we use truncated SHA-1 in v2 onion services and `relay_crypt_one_payload()`, and we use full width SHA-1 for relay fingerprints and, again, v2 onion services. Nick has also written [a draft document](https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-what-uses-sha1.txt) detailing where we use SHA-1, however it is presently outdated and incorrect in some places.