For now the Nyzo sentinel does not utilize proxies to initiate comms with in-cycle verifiers. In the currently nascent stage of the project this does not raise any particular concerns, however, this feature will be required for future generations which fall under more scrutiny and risk of attack. In short, Nyzo sentinels should be considered SINGLE USE for the time being, this due to the fact that the sentinel exposes its origin IP address to verifiers and can be intercepted by anyone receiving a data packet.

Since sentinels are a verifiers’ last line of defense, exposure of this IP address is undesirable and risky behavior.

Solution to the single-use problem

To mitigate the single-use problem I propose for an opt-out proxy feature to be implemented. This proxy feature should, ideally, leverage multiple proxies at once to establish communications with other verifiers. Extra configuration options should be added to the config file to manage correct operation of this feature.

proxies_enabled = True;

proxies_reusable = True;

proxies_source = 'proxy_list';

proxies_parallel_broadcast_amount = 5;

proxies_origin_fallback = False;

The first parameter is enabled by default — if enabled, the proxy_list file is called and its contents read into memory. If the amount of proxies in proxy_list is less than the proxies_parallel_broadcast_amount, the sentinel exits with an error and information on how to resolve this state is given.

In this case, upon broadcasting 5 random IP addresses are chosen from the file and used to establish communications. Once the frozenEdge has increased, all proxified socket connections are closed, as to prevent spam from reaching the sentinel through the proxy.

If proxies_reusable is disabled, the IP address is stored in memory and compared against the next time action is needed, if the number of IPs left over while proxies_reusable is disabled and the left over amount <= proxies_parallel_broadcast_amount, the verifier will resort to picking random proxies.

If proxies_origin_fallback is enabled the sentinel will, upon failing to use the proxies, use the origin IP address to establish communications.

Ideally the proxy list is read anew every time, this allows for a seperate process that scrapes IP addresses to be used by the user. There are no race conditions since the sentinel never writes to the proxy list file.

127.131.36.2:5412:user:password

127.132.37.3:5413

128.194.36.4:5411

128.144.36.5:5411

128.169.36.9:5411

This is an example of the proxy_list, with optional user:password addendum for proxy authentication.

Challenges with regular proxies

There are multiple challenges that come from using regular proxies, to name a few:

when using free proxies the lifespan and quality is not guaranteed

when using paid proxies the operational costs increase

when setting proxies_reusable to false the operational costs increase or the quality of propagation decreases

proxies may be flagged / blocked / on a black list (not as much of an issue if your proxies_parallel_broadcast_count is high enough)

Using Tor as a source of free proxies

A user could make it easy for himself and install Tor on the sentinel, making sure to not run Tor as root.

Out-of-the-box Tor provides us with a SOCKS5 proxy.

127.0.0.1:9501

Circuit switching is handled by Tor and can be influenced through the Tor controlport, but since we do not want to make any changes to the sentinel to support Tor, we have to find a separate solution. This proxy will work great but if a circuit becomes unresponsive, Tor’s inherent circuit regeneration is too slow for the Nyzo network and the node might drop out as a result of a bad circuit. Aside from that, it only gives us one proxy (circuit) and doesn’t aid the parallel broadcast idea from before.

Luckily, it is not hard to fix this and a simple modification to the torrc file allows us to open a multitude of circuits all at once. Example of the addendum required below:

SocksPort 9052

SocksPort 9053

SocksPort 9054

SocksPort 9055

SocksPort 9056

A proxy list configuration file might look like this when Tor is leveraged:

proxies_enabled = True;

proxies_reusable = True;

proxies_source = 'proxy_list';

proxies_parallel_broadcast_amount = 5;

proxies_origin_fallback = False;

The proxy list as follows:

127.0.0.1:9052

127.0.0.1:9053

127.0.0.1:9054

127.0.0.1:9055

127.0.0.1:9056

Going back to the challenges that arose from using regular proxies, lets see how Tor handles those:

when using free proxies the lifespan and quality is not guaranteed

→ The lifespan of all relays and exit nodes can be monitored, the parallel broadcast amount can be adjusted as a hedge

when using paid proxies the operational costs increase

→ Tor is free, but more on that below

when setting proxies_reusable to false the operational costs increase or the quality of propagation decreases

→ Tor handles circuits and provides us with new ones automatically

proxies may be flagged / blocked / on a black list (not as much of an issue if your proxies_parallel_broadcast_count is high enough)

→ Yes, a real issue for Tor exit nodes are black lists. Same principle applies.

Contributing to Tor

This part is entirely optional and should be viewed separate from what has been discussed above.

If Tor becomes a primary, free and reliable source for the Nyzo network’s sentinels to rely upon, it would make sense for the Nyzo network to contribute back to the Tor network. Again, this is entirely optional but my thought stream will make sense in a minute.

Currently the Tor network consists of 6000 relays (source):

The Nyzo queue consists of 13000 nodes (source):

Due to the design of the Nyzo verifier, the resources available on a low-tier VPS are barely used by a queue node. A queue node should, to remain eligible, broadcast at least once every 12h (or more, depending on mesh size). Aside from some minor tracking the bandwidth and CPU power of the verifier remains unleveraged.

Compared to networks based on electrical expenditures this is negligible and does not pose any ecological worry, however the unused bandwidth and CPU power can be leveraged to run a Tor relay aside a queue verifier.

As a test, I’ve ran a 1024 KBps relay for the past 14 hours and the CPU consumption is as negligible as that of a queue node. The queue node does not jeopardize its position if the Tor relay is properly configured. Anecdotal findings support the notion that a Tor relay does not smother a low-tier VPS.

Considering the amount of Tor relays in existence and the amount of queue nodes in existence, it speaks for itself that if the entirety of the queue adopted the idea the amount of Tor relays would triple and the Nyzo network would garner a certain amount of publicity for supporting the network.

Publicity aside, if/when the sentinels’ proxy feature gets developed and Tor becomes a popular source for free fallback proxies, supporting the source of said proxies is the “least” you can do to give back to the hand that feeds you. Tor and Nyzo both bolster diversity as its ingredient for success. It just makes sense.

Slide from Defcon27 (https://www.youtube.com/watch?v=ZB8ODpw_om8)

If you want to discuss this matter, feel free to join the Nyzo discord.