node-Tor - Javascript implementation of the Tor protocol

Community Grants Applications
1

Hi,

Please see the proposal we posted on ZF Grants node-Tor

node-Tor is the unique implementation of the Tor protocol in javascript working inside browsers and servers on any platform, the code is quite small for what it does (500 kB minified), optimized and very efficient, with zero dependencies, it can be used to anonymize whatever protocol/application, it should not be misunderstood with the Tor network and is not a remake of the Tor project code and related projects like torify

The github repo is here

Since I am new here unfortunately I cannot post more than two links in this post, so continuing this short presentation without links

The description of phase 4 to be funded is in the github repo phase 4 and 5, see also the technical documentation for the Evented pipe methods

To summarize despite of all the docs and recent complete repackaging node-Tor remains a bit difficult to use in its current state (phase 3), phase 4 (Evented pipe methods) is when it becomes easy to integrate/use and I am not required any longer to assist

For a brief overview and use case for zcash and others, please see the Examples - Use cases section

This proposal is for phase 4 but the ultimate target would be Convergence-2020 (see the link again in the repo) “A universal and generic architecture to anonymize any application or protocol and turn it into an independent decentralized p2p network inside browsers and servers, with browsers acting as servers”

Feedback/comments/questions welcome

6 Likes
2

Welcome to the forum @Ayms

It’ll make the discussion much easier if you just copy paste what you wrote on grants platform, to your post above. That way people can quote on which part(s) they have question for.

Btw, have you reach out to any zcash node/app developer regarding this specific proposal? I cannot find any specific point on how your project would benefit zcash directly. Context: the major grants is restricted to projects that further zcash and its ecosystems.

Cheers

1 Like
3

Yes, probably, the problem is that I am limited with two links and the proposal have more, thanks if someone can remove this limitation

I have reached out zcash devs in the past, for other purposes (BIP32 · Issue #1893 · zcash/zcash · GitHub), regarding the current proposal and application to zcash please see RFC: Introducing AltNet, a pluggable framework for alternative transports by ariard · Pull Request #18988 · bitcoin/bitcoin · GitHub and bitcoin-dev/2021-December/019668.html

Obviously also the project can be used for wallets and light clients

1 Like
4

I have bumped up your trust level. You should be able to edit your post now. Sorry, I forgot that you’re a new user.

I believe the community would be more inclined toward this proposal if you create/comment a PR in zcash repo instead of other crypto project repo. :sweat_smile:

5

Some feedback:

6

Thanks, please see below the grant proposal, I could indeed post a zcash issue, now the situation is the very same than with bitcoin, see the bitcoin-dev post and github bitcoin discussion, please (some people) prove me that I am incorrect but I don’t find serious the use of the Tor network for zcash/others and let people play with the torrc file the way they like, the use of the Tor network for zcash and others is not the right solution, it’s even dangerous due to some specific Tor network features, the right solution is to have zcash nodes/clients implement the Tor protocol as a real P2P network

@Shawn it does worth it, definitely, this project is usually misunderstood

Applicant background

I have been involved since quite some time in privacy/security projects and did participate in many lists/groups (W3C, ecmascript, browsers bugs report, liberationtech, Tor, p2p-hackers, webp2p, etc)

I was a member of the W3C WebCrypto working group, and as such suggested many things related to the Tor protocol, I did motivate also the revival of the W3C (dead and depecrated) Streams API and helped to adapt it to what is needed today

I am also registered as security/privacy expert at the EU level and did participate as evaluator of cybersecurity H-2020 proposals

I am in contact with the Tor project people since the beginning and did report some bugs in the Tor bug tracker, I am also in contact with many people in the community including devs and academics

For more information please see https://fr.linkedin.com/in/aymeric-vitte-05855b26 and http://www.peersm.com/CVAV.pdf

Description of Problem or Opportunity

The problem today is that we must invent one network per need if we want to evade big data centralization and protect privacy/anonymity: to browse, to chat, to email, to exchange files, to do social networking or cooperative work, to do crypto currency, to protect the users from their
connected objects, to handle peer identities

node-Tor allows to anonymize any protocol on any platform fix or mobile, it has the unique property to work inside browsers also, please see some of the use cases/discussions here: GitHub - Ayms/node-Tor: Javascript implementation of the Tor (or Tor like) anonymizer project (The Onion Router)

Proposed Solution

The ultimate target of node-Tor would be the Convergence proposal: A universal and generic architecture to anonymize any application or protocol and turn it into an independent decentralized p2p network inside browsers and servers, with browsers acting as servers

For this grant we propose to finish and release phase 4 of node-Tor implementing the evented pipe methods allowing to pipe any protocol with node-Tor, including bitcoin/zcash, wallets, spv clients, please see GitHub - Ayms/node-Tor: Javascript implementation of the Tor (or Tor like) anonymizer project (The Onion Router)

Solution Format

Open source node-Tor js code and associated documentation in github repo GitHub - Ayms/node-Tor: Javascript implementation of the Tor (or Tor like) anonymizer project (The Onion Router)

Technical approach

node-Tor should not be misunderstood with the Tor project code and features, this is a complete implementation of the Tor protocol not mimicking some specifics of the Tor project which are dedicated to be used with the Tor Browser

The complete code is quite small for what it does, only 500 kB minified, with zero dependencies since everything is embedded in the code (crypto, etc)

How big of a problem would it be to not solve this problem?

Current use by bitcoin/zcash and others of the Tor network is not appropriate, even dangerous, the Tor network is small and centralized, it is intended to be used via the Tor browser with many specific features that do not apply to crypto currencies, and it is not dimensionned to absorb crypto currencies traffic neither designed to anonymize transactions and nodes, please see this discussion [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

But as showned above in the use cases, the goal is not limited to crypto currency networks, it can apply to any protocol like visioconf, covid apps, etc

Execution risks

There are no risks, while the documentation is already available it remains difficult to use node-Tor in its current state despite of the fact that it is now modular and ES6 like, phase 4 is when it becomes easy and when I am not required any longer to integrate/extend it

Unintended Consequences

As always with this kind of project, if it can be used to protect people then it can be used to do the contrary and/or by “bad” people

Evaluation plan

While releasing phase 4 we will revive the Peersm demo, which is a demo of node-Tor inside browsers where the browser is implementing the Onion Proxy function allowing to anonymously fetch web resources (not to be misunderstood with browsing) and download content from other browsers running Peersm also, see the configuration here (using browsers, node-Tor nodes and Tor network nodes) : GitHub - Ayms/node-Tor at c98db366ada656c20131d07fe071ba9737805c2c

Schedule and Milestones

Two months

Budget

The project is currently stuck between phase 3 and phase 4, so phase 4 is partially implemented (funded by myself), we estimate two months to finish it and set the Peersm demo, so a total of 5 months with 10K USD per month, which is comparable to EU Grants rate of 60 E/hour for 140 hours a month

2 Likes
7

Sorry, I don’t understand your comment, Peersm (http://www.peersm.com) was the first project to bridge with bittorrent anonymously and allow to stream live

Browsers are a nightmare indeed, not node-Tor, inside browsers it’s a webapp, nothing to do with browsing, and you can check the code, see Discover and move your coins by yourself

It takes more than 3mn to understand this and the details must be read

8

I don’t personally have an opinion on this grant, the technical aspects of implementing it are a bit over my head.

I only posted to solicit feedback from those in the community that know more about this than I do. It’s up to ZOMG to look at the proposal itself and feedback to form an opinion.

9

Have you checked out the Arti grant, btw? Just out of curiosity.

It’s great that if you think this can benefit zcash. However, I would prefer if there’s real plan to implement this in any of the zcash app/node. Without that, I can’t see how zomg can fund this specific proposal.

10

Yes Willingness to help on porting tor to wasm. · Issue #19 · Ayms/node-Tor · GitHub

That’s why I am posting here

I am very skeptical about the outcome of this Arti stuff, especially inside browsers/mobiles, please keep in mind that node-Tor is 10 years old with a huge work to optimize everything, and is very efficient and small, which can’t be the result of hazardous recompilation over compilation/decompilation, without having serious solutions for storage & co

Anyway again, this is different, node-Tor is not intended to support the Tor Browser/Network specific features, I don’t see really how Arti will benefit to zcash

The implementation for zcash is explained here RFC: Introducing AltNet, a pluggable framework for alternative transports by ariard · Pull Request #18988 · bitcoin/bitcoin · GitHub , via stdin/stdout or unix sockets

11

Paging @little.slingshot @mistfpga @1337bytes and to every Zcasher who is actively working on JS/browser based products for Zcash. Do you see a path to integrate tor in your products?

7 Likes
12

Arti is meant to be integrated into apps. The idea is Zcash daemons will eventually natively ship Tor and offer full Tor networking functionality, and a Rust project which can do that while easily enough working with C, C++, and all other compiled languages is a massive benefit.

While node-Tor has its own benefits, I mainly see it as beneficial for the fact it can run in a browser. On an OS, we have the existing non-bundled Tor service (though I think you may have some comments about OS-level transport security I’m not fully understanding), and within an app, I much rather grab a Rust library than the node runtime and try to embed it that way.

While I won’t say this doesn’t have benefit to Zcash, as Tor definitively does and @aiyadt has pinged people who may use this, I will say this proposal doesn’t currently define the benefit to Zcash, so I’m interested to hear more about that.

3 Likes
13

Arti is meant to be integrated into apps.

So is node-Tor

offer full Tor networking functionality

What does this mean? Full Tor functionnalities do not apply to P2P networks, this is even the contrary, Arti is proposing some adaptations, not very convincing knowing that you can’t modify the basics, like for example the Guards concept

and a Rust project which can do that while easily enough working with C, C++, and all other compiled languages is a massive benefit.

There can’t be any magic or approximation with this kind of projects, I don’t believe you can transpose the Rust code to any platform in a secure and efficient way, or this would be a miracle

While node-Tor has its own benefits, I mainly see it as beneficial for the fact it can run in a browser. On an OS, we have the existing non-bundled Tor service (though I think you may have some comments about OS-level transport security I’m not fully understanding), and within an app, I much rather grab a Rust library than the node runtime and try to embed it that way.

Yes plenty of comments, by default the browser/node code should apply everywhere, ie the very same code everywhere, not sure why you don’t like node, this easily interacts with whatever app

While I won’t say this doesn’t have benefit to Zcash, as Tor definitively does and @aiyadt has pinged people who may use this, I will say this proposal doesn’t currently define the benefit to Zcash, so I’m interested to hear more about that.

Why “Tor definitely does”? Again the Tor network is not appropriate for zcash

And maybe I forgot to mention that the anonymizing nodes with node-Tor are of course the zcash nodes and clients, not necessarily the Tor network nodes, but both can be used, outside of the Tor network consensus system

1 Like
14

By integrated into apps, I meant on the binary level. The cited Bitcoin issue wants node-Tor to effectively replace the standing Tor daemon for now, without native integration, and any native integration would require shipping the full JS runtime in the application.

By full functionality, I really just meant being able to connect to the Tor network and securely send data over it to achieve network level privacy as much as possible. That said, Arti is intended to implement all of the Tor protocols.

I personally use Rust exposed via a C FFI in my Nim work. You can argue it’s insecure because I do use raw pointers for the C FFI, which violates the memory safety Rust offers, yet I don’t imagine any JS engine bindings would be better. I will note I don’t crossover any async work, which sounds like a monumental task, yet that’d be true for both Rust and JS. It’s effectively a pair of header files (one C++ header, one Rust copy of the function definitions) and my binary solely executes native code with 0 overhead.

I don’t dislike node-Tor. I think it sounds best left to the browser side of things. If I have a C++ app, such as zcashd, and I want to give a single executable to my users which utilizes the Tor network for privacy, how would you recommend doing this with node-Tor? I personally detest the idea of grabbing V8, spawning it up in my app, piping the scripts to it, and then defining custom bindings for the actual functionality compared to grabbing a Rust library which would be immediately accessible under Rust, and C++ with just a header file. Even if you provide bindings from node-Tor to C++ yourself which manage a V8 instance accordingly, why do I want to ship the memory hog known as V8 in my performance-focused C++ app? If node-Tor is run as a separate binary, as suggested by the Bitcoin issue, what benefits does it offer over just running the stock Tor daemon? That was my comments/questions with that paragraph.

When you define the Tor network as a set of nodes running the protocol considered as Tor to offer network privacy, such functionality is critical to Zcash. Even now running Zcash behind Tor will greatly increase your privacy, even if it doesn’t take advantage of aggregate traffic with other nodes due to the lack of people running Zcash over Tor. I don’t know why you’d say it’s not appropriate.

Your final comment states this wouldn’t be used to link up with the thousands of Tor nodes out there providing access to the entire internet with privacy (though they could be). At that point this effectively becomes a Dandelion++ functional equivalent except it’ll greatly reduce performance if we blindly route all traffic over it, no? The reason I’d want to use Tor with Zcash is so no one knows I’m running Zcash in the first place. If I spawn a Zcash nodes, which has the Tor protocols yet not the Tor network, and I immediately connect to a bunch of Zcash nodes, it’s obvious I’m running Zcash. Then, as it’s a public blockchain (just with some data not saved to the blockchain yet rather committed to and proved), I don’t care for privacy because everyone knows everything except for new TX publication on my end. That’s why this effectively becomes a discussion against Dandelion++ which offers a privacy protocol for that.

As one final note, I do understand running a node behind Tor would also greatly reduce performance. The distinction is that no one even knows I’m running a node without potential theoretical government level attacks (packet size analysis across entry/transport/exit nodes with low population of similarly sized packets) whereas if I’m solely connecting to Zcash nodes, that advantage isn’t there.

That may be our fundamental misunderstanding though. I’m coming from this discussing integration with the Tor network. If you’re suggesting zcashd form its own network privacy system, that’s just a different discussion that what I thought it was, and I’d be interested in discussing that. If it is discussing the Tor network, or if it’s discussing both, I’d love to hear an explanation on why this is better suited for integration with Rust/C++ projects than Arti, as well as clarification on why it’s better than the standard Tor daemon if not meant to be integrated on such a level. If it’s solely discussing a Zcash network privacy solution limited to the Zcash network, then the question really does become how much better is this than Dandelion++. They may both be fine yet this may be faster to integrate. Cool if so.

EDIT: I saw your grant proposal linked a BTC mailing list email I had yet to read. I actually commented on how such an attack is possible here: Is Zcash actually quantum private? - #23 by kayabaNerve Interesting to see you also discussed it a few weeks ago. While that does mean nodes are still identifiable behind Tor, it doesn’t mean they’re trackable to where they’re running, which is what I’m promoting as the reason to use Tor with nodes. I can also promise you the Zcash network is much smaller than the Tor network so that aspect of the problem remains unchanged. The only benefit would be if node-Tor offers the fine grained circuit control I say would be needed in the thread I linked AND the existing Tor daemon does not expose such functionality. At that point, I’d ask what/how Arti is doing before coming to node-Tor.

3 Likes
15

I agree that linking node-Tor to a C/C++ or a non nodejs app is not completely straight forward, because I did not choose the easy way solution, ie a SOCKS proxy, which of course works with node-Tor also

And indeed using node-Tor inside browsers is completely straight forward

Now your issue would be to package everything and pipe into node-Tor, then you prefer to use the Tor daemon, that’s where I am not following you, because even if you can package everything you will be forced to use the SOCKS proxy, prone to security breaches, as stated in the bitcoin posts, so you have everything together but still you must send the messages “outside”

That’s how it is today but as far as I understand Arti is supposed to replace the SOCKS proxy by embedded code, however that’s not super clear in the Arti repo right now where SOCKS remains the default

Using zcash nodes as anonymizing nodes is an option, this can be combined with browsers acting as nodes, and standard Tor network nodes, unfortunately this is not for tomorrow (please note that the Peersm project was doing this 8 years ago bridging with bittorrent, when will this happen at last in the world remains mysterious), and of course if such anonymization system is used, you are not supposed to know who is doing what (ie your concerns connecting to zcash nodes), maybe take a look at http://www.peersm.com/Convergence-2020.pdf

The Tor network is designed to be used with the Tor Browser, is quite small and centralized, with many features that do not apply to p2p networks, I gave a simple example in the bitcoin-dev email, this is indeed what you are addressing in your EDIT link/post (funny to see that you raised those issues at the same time I am posting here) , then you summarize very well some of my points, can you choose nodes, circuits, load distribution, paths with the Tor daemon ? No except if you are a super expert or you hack the Tor project code. Will Arti solve/improve this? I don’t know

So I am not saying that node-Tor is better or whatever, I am saying that you can really control what you are doing with node-Tor, then yes you can do what would be needed in your thread, by default it creates 5 circuits + 1 toward a RDV node, load is distributed between those circuits, they are monitored and renewed periodically, you can customize all of this and decide which nodes you trust (see node-Tor/README.md at master · Ayms/node-Tor · GitHub)

BUT, after writing this and looking again at my docs I realize (very) lately that my zcashd | node-Tor | zcashd does not work very well, not at all in fact, because there is no notion of request and everything is piped into the same circuit without easy generic way to recover if the circuit breaks or change/distribute the load between circuits, we could revert to a SOCKS proxy stuff but I am not a fan

Strange that nobody until now pointed out this, but the behavior is different inside browsers and nodejs (or via SOCKS), since each pipe is associated to a request/stream that will select one circuit available unless the implementation decides otherwise

So let’s hope that I did not waste your time here, you can dismiss the proposal or decide to fund the browser/nodejs use

1 Like
16

That level of circuit control is what I’d personally expect from Arti, yet we’ll have to wait and see exactly how it ends up. As for controlling the Tor daemon, isn’t fresh circuits possible via (at worst) clearing its data and starting it up so it’s forced to find fresh circuits? Sure, they could naturally overlap, yet the Tor network circuit potentials is as large of a pool as we can access with regards to Zcash. Zcash nodes themselves would provide a much smaller set, but it would be cool if Zcash nodes did further increase the Tor node quantity.

The level of control offered by node-Tor is still extremely interesting to me :slight_smile: Not to mention the browser access. I’m not a member of ZOMG so my opinion doesn’t really matter here, but I still appreciate the project and hope it continues its successes. Best of luck with it :slight_smile:

2 Likes
17

I can definitely imagine a reality where we support this idea. Unfortunately timing might be the enemy here and the ecosystem just isn’t ready to commit/consume this :sweat:. Happy for anyone, including those mentioned, to suggest otherwise :smiling_face:.

No wasted time :+1:.

Just to give a random community member’s option/vote I unfortunately think we might not be 100% ready for this and don’t recommend we fund it :sweat:.

1 Like
18

@kayabaNerve thanks, same for your projects

It would be interesting to know how Arti intends to implement the embedded part and give the level of control that gives node-Tor, hopefully not via an unbelievable torrc file

I don’t know for the Tor daemon, a bad advise probably would be to kill it periodically and respawn it, very shxtty solution of course since zcashd would need to sync with this and, still, you can’t be sure about the path chosen

I don’t think also that the Tor project is enclined to add (plenty of) nodes, because it makes it more difficult for them to control the network

node-Tor allows to select Tor network working nodes, testing them, the result is always the same since years : 1000 guards, 1000 relays, 1000 Exit, with an intersection not null between them of course

Now if we come back to the zcashd hidden nodes, node-Tor does not implement hidden services (because onion addresses stuff…) but the RendezVous protocol

It is simple, nodes advertise to the RDV nodes some hash via two or three hops (for a file, or for Zcash let’s say the hash of “Zcash”), then the RDV nodes connect the two nodes requesting/advertising the same hash, nobody knows who is who, maybe too simple for the hash part but probably it’s up to the upper layer to add more security, like end-to-end encryption (since the RDV node has everything in clear), or avoid eclipse attacks (since the hash can be faked), and DHT, but adding to this the concept of hybrid nodes in the Convergence proposal (ie nodes can be both RDV/normal nodes and can extend to others), then it becomes quite difficult to know who is doing what

That’s how works part of the Peersm demo, you store a file inside your browser (indexedDB) via Peersm interface, Peersm inside your browser will advertise the hash to the RDV nodes anonymously, others can download the file anonymously just using the hash from their browser with the Peersm demo app, and “others” are normal people, I am not aware of a better solution, in this covid area I saw some recent kind of censorship where people were trying to raise some concerns via videos including unfortunate copyrighted stuff, then immediately shut down by dmca notices, normal people again, they don’t know Tor, bittorrent & co, they know browsers, and of course no dmca notice can ask you to remove a(n) (anonymous) file inside your browser

@GGuy , for the “not ready” statement, please see Anonymous Robert - Consider using node-Tor · Issue #55 · ROBERT-proximity-tracing/documents · GitHub , just look at “Any protocol implements somewhere in a central place” section which explains how to use node-Tor easily (phase 4), then any implementation is supposed to be ready for this

Repeating myself, but node-Tor is more than 10 years old, maybe we should be ready for something like this one day

Why should zcash fund the project? Why not? Then reverting the question: why is zcash funding Arti?

All p2p/privacy lists are dead right now or since some time, including Zooko’s one, seems like nobody care any longer

See this also Re: Mesh networks and PeerConnections in Workers - what I heard from Aymeric Vitte on 2022-01-25 (public-webrtc@w3.org from January 2022) and other comments in this thread, W3C trying to understand P2P, funny stuff, when can all of this happen?

19

I support this project being funded.
I believe in the multiple use cases. I believe the developer is on top of the project as it morphs. The arti project is looking good but we need more than one solution for any given challenge. As well, good communication skills. I hope you stay involved regardless of the outcome of your proposal.

20

Thanks, interesting feedback here (I would say for once… people understanding what this project is about)