[tor-dev] Hacks to reduce Tor's initial download on slow Internet, sacrificing privacy?

Hi everyone,

Is there a way right now to get Tor hidden service functionality (hosting a hidden service, connecting to hidden services) on a connection where the Internet is so slow and unreliable that the initial download of network information currently takes ~forever, provided one is willing to sacrifice metadata protection?

Is there a way to download, say, 100x less network information on startup and still effectively host and connect to hidden services? Or is there a way to hardcode network information with the client, since that can be installed before going into the slow Internet zone, from a CDN that is less impacted, or from a source on the local network? (I read that this is how Tor worked in the past?)

The context is the following:

I have a p2p messaging app that uses Tor and hidden services (Quiet) in a way similar to Ricochet or Onionshare. I’m going to a conference where last year the Internet was so slow that Tor’s initial download of network information took too long and kept timing out, rendering Quiet unusable. The Internet was, however, fairly reliable and usable for e.g. web browsing and messaging. I’d like to be able to use Quiet at this conference. It would be used purely as a demo for a few days, and we could warn everyone that our use of Tor did not offer its typical security properties. (Then in future years we might support p2p connectivity over local wifi, like Briar does!)

My understanding is that the network information download step is to protect users against epistemic attacks. My intuition is that for situations where this doesn’t matter there is some way to use Tor with a small subset of the network information and that the initial download could be skipped.

Is this true? What’s the best way to do it in the Tor client we ship?

(I’m familiar with the Walking Onions paper, but looking for something that is ready now. There isn’t already an implementation of Walking Onions, is there?)

Thanks!
Holmes

Hi everyone,

Is there a way right now to get Tor hidden service functionality (hosting a hidden service, connecting to hidden services) on a connection where the Internet is so slow and unreliable that the initial download of network information currently takes ~forever, provided one is willing to sacrifice metadata protection?

Is there a way to download, say, 100x less network information on startup and still effectively host and connect to hidden services? Or is there a way to hardcode network information with the client, since that can be installed before going into the slow Internet zone, from a CDN that is less impacted, or from a source on the local network? (I read that this is how Tor worked in the past?)

The context is the following:

I have a p2p messaging app that uses Tor and hidden services (Quiet) in a way similar to Ricochet or Onionshare. I'm going to a conference where last year the Internet was so slow that Tor's initial download of network information took too long and kept timing out, rendering Quiet unusable. The Internet was, however, fairly reliable and usable for e.g. web browsing and messaging. I'd like to be able to use Quiet at this conference. It would be used purely as a demo for a few days, and we could warn everyone that our use of Tor did not offer its typical security properties. (Then in future years we might support p2p connectivity over local wifi, like Briar does!)

My understanding is that the network information download step is to protect users against epistemic attacks. My intuition is that for situations where this doesn't matter there is some way to use Tor with a small subset of the network information and that the initial download could be skipped.

Is this true? What's the best way to do it in the Tor client we ship?

If you include a Tor data directory with a fresh set of the cached microdesc consensus and microdesc descriptor documents in your app distribution, and *also* hack REASONABLY_LIVE_TIME in src/feature/nodelist/networkstatus.c to be as long as you expect that release to be published, I think this gets you what you want.

The default is 24 hours, which means that clients will accept these cached documents for up to 24 hours as valid, before blocking everything to download a new one.

So you can hack this value to be much higher (at the cost of increased risk to clients from being fed a stale consensus continually), and refresh your download files to include new documents, once per time window.

I think this will work, but I would not be surprised if you hit a few other "safety" checks that are elsewhere in the codebase, other than that #define, that you also have to change.

(I'm familiar with the Walking Onions paper, but looking for something that is ready now. There isn't already an implementation of Walking Onions, is there?)

No. Also arti-relay impl will mean fewer relays in the consensus, because of multicore support. It will also probably mean better consensus diff support. But that isn't done either.

···

On 5/3/23 17:24, Holmes Wilson wrote:

--
Mike Perry
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

This is what I was looking for. Thanks!

···

On Mon, May 8, 2023, 4:56 PM Mike Perry <mikeperry@torproject.org> wrote:

On 5/3/23 17:24, Holmes Wilson wrote:

Hi everyone,

Is there a way right now to get Tor hidden service functionality
(hosting a hidden service, connecting to hidden services) on a
connection where the Internet is so slow and unreliable that the initial
download of network information currently takes ~forever, provided one
is willing to sacrifice metadata protection?

Is there a way to download, say, 100x less network information on
startup and still effectively host and connect to hidden services? Or is
there a way to hardcode network information with the client, since that
can be installed before going into the slow Internet zone, from a CDN
that is less impacted, or from a source on the local network? (I read
that this is how Tor worked in the past?)

The context is the following:

I have a p2p messaging app that uses Tor and hidden services (Quiet) in
a way similar to Ricochet or Onionshare. I’m going to a conference where
last year the Internet was so slow that Tor’s initial download of
network information took too long and kept timing out, rendering Quiet
unusable. The Internet was, however, fairly reliable and usable for e.g.
web browsing and messaging. I’d like to be able to use Quiet at this
conference. It would be used purely as a demo for a few days, and we
could warn everyone that our use of Tor did not offer its typical
security properties. (Then in future years we might support p2p
connectivity over local wifi, like Briar does!)

My understanding is that the network information download step is to
protect users against epistemic attacks. My intuition is that for
situations where this doesn’t matter there is some way to use Tor with a
small subset of the network information and that the initial download
could be skipped.

Is this true? What’s the best way to do it in the Tor client we ship?

If you include a Tor data directory with a fresh set of the cached
microdesc consensus and microdesc descriptor documents in your app
distribution, and also hack REASONABLY_LIVE_TIME in
src/feature/nodelist/networkstatus.c to be as long as you expect that
release to be published, I think this gets you what you want.

The default is 24 hours, which means that clients will accept these
cached documents for up to 24 hours as valid, before blocking everything
to download a new one.

So you can hack this value to be much higher (at the cost of increased
risk to clients from being fed a stale consensus continually), and
refresh your download files to include new documents, once per time window.

I think this will work, but I would not be surprised if you hit a few
other “safety” checks that are elsewhere in the codebase, other than
that #define, that you also have to change.

(I’m familiar with the Walking Onions paper, but looking for something
that is ready now. There isn’t already an implementation of Walking
Onions, is there?)

No. Also arti-relay impl will mean fewer relays in the consensus,
because of multicore support. It will also probably mean better
consensus diff support. But that isn’t done either.


Mike Perry


tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev