Right now we're exploring latency-based attacks but are having trouble achieving a particular goal: a way to “ping” an arbitrary node in a client’s already-built (“live”) circuit. One-way timing is ideal but round trip time would suffice. We can glean this information during circuit construction, but what about a “live” circuit? Ideally, this would be a periodic thing Tor already keeps track of, but as an on-demand or as a byproduct/side-effect of a different function would also work. We have not been able to find a way to do this within the Tor (sub)protocol specs or the control port spec.

Use OnionCat and ping6, it is exactly what you want. https://www.onioncat.org/ Such "timing" attacks are in the scope of "Tor Stinks -- NSA" document. Users should become familiar with them, and that slide deck, and other attacks from over a decade ago. And with how tor does not address them.

Hey, On 21.01.22 14:57, Alexander Mages wrote:

Right now we're exploring latency-based attacks but are having trouble achieving a particular goal: a way to “ping” an arbitrary node in a client’s already-built (“live”) circuit. One-way timing is ideal but round trip time would suffice. We can glean this information during circuit construction, but what about a “live” circuit? Ideally, this would be a periodic thing Tor already keeps track of, but as an on-demand or as a byproduct/side-effect of a different function would also work. We have not been able to find a way to do this within the Tor (sub)protocol specs or the control port spec.

You can measure the RTT between your client and a node by exiting through that node and intentionally violating its exit policy, such as connecting to 127.0.0.1:80. The node will return an error, and you can measure the RTT as the time between sending the request and receiving the error. See https://naviga-tor.github.io/ for an example. All the best, Robert