Nym v0.8.0 Released

Dave Hrycyszyn
Sep 10, 2020 · 5 min read

We are very pleased to announce the availability of version 0.8.0 of the Nym platform. It’s our biggest release ever!

Most of the work over the summer has been focused on mixnet reliability, new privacy features, and ease-of-use.

Let’s get into it.

SURBs for reliability and replies

We now have Single Use Reply Blocks (SURBs) working. SURBs allow two parties to communicate with each other while preserving their anonymity.

How are they used?

SURB-acks

A Single Use Reply Block Acknowledgements, or SURB-ack, is now sent with every packet, giving a major boost to mixnet messaging reliability.

If Alice sends a message to Bob, the gateway node for Bob will send back the SURB-ack upon receipt of each message packet from Alice. If Alice’s client does not receive an ack for any part of the message, it will retransmit (with an exponential back-off) until a SURB-ack is received or she concludes that the ack’s not going to happen. This packet retransmission mechanism provides a major reliability boost.

SURB-acks are anonymous: Bob’s gateway has no idea who sent the message or who it’s replying to.

Why does the gateway acknowledge receipt instead of Bob’s client? Bob may be offline, but the gateway is up 24/7 and can store messages for Bob. He will get them when he comes online. And Alice gets speedy confirmation that her message can be read by Bob (when he wants to read it).

SURB-replies

Single Use Reply Block Replies (or SURB-replies) also now work in v0.8.0 (with one limitation, see below). When sending a message to Bob, Alice can attach a SURB-reply within a given Sphinx packet, and if Bob wants to reply, he can do so despite not knowing anything about Alice. This is because the SURB-reply is generated entirely by Alice. Bob never sees the contents of the backwards route because it’s been packed inside a Sphinx packet header by Alice. He attaches his response message to the header and the mixnodes carry it back to her.

Community Contributions

We have multiple community contributions in this release.

  • HansBricks built a Docker container for mixnode deployments.
  • A cool React example chat application was contributed by Kevin Foesenek.
  • a Systemd init script and some other platform code tweaks from Stefan Steinert.

Meanwhile, mileschet has been working on iOS and Android mobile support.

Thanks to all of you for the contributions!

SOCKS5 Support

The biggest news of this release is our new SOCKS5 client. This is paired up with a corresponding Service Provider called SphinxSocks, suitable for use by any cryptocurrency wallet that supports the SOCKS5 protocol.

The SOCKS5 client can be run on a local machine, e.g. your laptop. When you start the client, you specify which SphinxSocks service provider you would like to handle requests for you. All your traffic will then go through the mixnet, and SphinxSocks will make network requests on your behalf. Responses are piped back to the originating application and reassembled after going through the mixnet on the return journey. The proxy and service provider work together transparently: the application itself doesn’t even notice a mixnet was involved!

Since we want to make it practical for sysadmins to run SphinxSocks without undue stress, it ships with a default list of allowed requests that it can make — we have catalogued the requests made by the Blockstream Green and Electrum wallets and put them in the default allowed list for SphinxSocks. This gets around the ugly problem of running open proxies. Please help us add approved URLs for more wallets!

The SOCKS5 client allows existing applications to pipe their traffic through the Nym mixnet. It’s currently a console application, although we plan to build a simple GUI for it at some point in the autumn.

It’s worth pointing out that our SOCKS5 client temporarily has one limitation.

As noted above in the discussion of SURBs, we have basic sender anonymity working in the mixnet. We also have what’s called “Third-party” anonymity — defence against strong attackers who can keep the entire network under surveillance. This is a capability that no other system you can use today provides, and it’s pretty cool.

But in order to get Third-party anonymity working, our code currently has a serious and inconvenient limitation: responses needs to fit inside one response packet (SURB-reply) — see Ania’s deep-dive blog post for more on this. This makes it impractical to use with most existing applications right now.

As a result, in this version (0.8.x) of the mixnet, we are sending the client’s address from the SOCKS5 client to SphinxSocks to deal with the fact that the response may be larger than 1 packet. We have a solution for this (basically, send more SURB-replies so that the response can be of arbitrary size). That will be coming soon.

We are also working on an addressing scheme to allow both sender and receiver anonymity for hidden Nym service providers — allowing anonymous parties to communicate without ever learning each others’ identities.

As a result of all the changes in this release, the SOCKS5 client is speedy and reliable — here’s a screenshot of doing Bitcoin testnet transfers while streaming 1080p video over our QA mixnet (6 single-core mixnodes within Europe).

We’re not recommending that anybody routinely watches video over the mixnet (yet), but it is a big achievement to achieve this kind of throughput, and we’re very pleased!

Our first target usage of the mixnet is to provide strong network-level privacy defences for cryptocurrency transactions. The ability to stream video builds our case that mixnets are practical, usable technology, and provides a bit of proof that we can defend much of the world’s crypto traffic from third party network surveillance.

Note: although we’re excited that Nym is now more usable, we do not recommend depending on the Nym mixnet for strong privacy yet. We are working to get sender and receiver anonymity coded up, after which a full audit will be needed. But we are making very steady progress, and we invite you to try the mixnet today and give us feedback about how things go.

Incentives and Rewards

Lastly, we are also launching our tokenized testnet as well as giving rewards in BTC.

We have issued a token (without value, like all testnet tokens) to allow us to stress test the next phase of the development of Nym.

We have already rewarded some of our testnet nodes in BTC — many of them have been with us since our testnet was launched at the Chaos Computer Congress in 2019.

We’ll be doing rewards and bug bounties at regular intervals, to be paid in BTC. So run up a mixnode using Nym v0.8.0 and visit our signup form at https://nymtech.net/incentives/ to get started!

nymtech

Building the next generation of privacy infrastructure