[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Shrink Tor binary size





On Mon, Jun 27, 2022 at 5:03 AM Sergey Ponomarev <stokito@xxxxxxxxx> wrote:
I’m working on a firmware for routers based on OpenWrt  and it needs
Tor out of the box for NAT punching i.e. SSH and Web admin access. It
will expose a Single Onion Service i.e. not "hidden" with just 3 hop
for a better performance.

Hi, Sergey! This sounds like a neat project.

The Tor is already ported to OpenWrt but its binary is more than 2mb.
For 16mb routers this is not critical but a lot and I need to keep
space.
So is it possible to compile Tor without some features?
As far as I understood from autoconf I can disable Relay functionality.
But maybe I can also disable some admin api parts and SOCKS proxy.
Also OpenWrt out of the box has WolfSSL so is it possible to compile
tor with it instead of OpenSSL?


So, you've seen the options  `--disable-module-relay` and `--disable-module-dirauth`, and those are the only ones there are at the moment.  We don't support WolfSSL, but you could try it out (it supposedly has an OpenSSL compatibility layer?) and see if it works.
 
Another problem is files sizes inside of /var/lib/tor/:
     20,442 cached-certs
2,303,443 cached-microdesc-consensus
8,725,598 cached-microdescs.new
       3,531 state

I think that all these files may be minimized. E.g. cached-certs
contains keys in PEM format which is just Base64 form of DER.
So switching to plain DER certs can significantly reduce size.

That isn't likely to happen at this point in the lifecycle of the current directory system; your best bet here is to look in to some kind of compressing filesystem.  You _might_ be able to save a little space by tinkering with the definition of TOLERATE_MICRODESC_AGE and setting it to 3 days instead of 7, but I don't know how well that would work.

I do want us to move to a world where we need a lot less storage to run a client, but that will require an implementation of the "Walking Onions" design [1], which probably won't be possible until we've got a full relay and authority implementation in Arti [2].

[1] https://gitlab.torproject.org/dgoulet/torspec/-/blob/master/proposals/323-walking-onions-full.md
[2] https://arti.torproject.org
 
As a side question: is it possible to make a small relay proxy that
can work part time when I sleep?
Imagine that each router already has a Tor. This is potentially
thousands of relay nodes and all of them have a motivation to support
the network which they are using themselves.

But users don’t want to lose bandwidth. I see that I can set some
traffic or bandwidth limits.
But maybe I can write some script that will enable or disable the
relay by schedule in the evening.
As far I know relays must be always online so this will make the relay
unstable and it won’t be used by Tor.
Is it technically possible?

It's a cool idea, but it's not something we support with our current design.  To deliver good performance to users, we need relays to have good, fast, reliable connections.  Having a relay that drops off the network once a day, or that changes its capabilities too frequently, doesn't really work so well (as I understand it).  This is an area where others understand the design space better, though, so maybe somebody will figure something out.

cheers,
--
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev