Better client and server network level privacy (edited)

Please add a feature where entrance and exit paths are setup separately where the client maintains an entrance node connection then can rotate between exit nodes

And please add a feature where the nym Dameon by default keeps at least an entrance node connection and uses it to communicate with validators

This also has the benefit of massively boosting privacy of nym users on phones since in this way they don’t need to use resources on maintaining a 5 or 2 hop connection especially once who are on big public WiFi Networks where non nym traffic is already exiting

And since most phones have severe tracking problems this would mean that the 3 mix hops don’t have a possibility of being known already via a back door and then being used to deduce still private paths this would also be good for windows users who are not actively using nym but want to contribute to the anonymity set by donating their ip address while using minimal resources

This goes along with entrance nodes being more of a guard node functionality where the path data would be encrypted and downloaded through the entrance node using a separate key then the tunnel along with zkp so each node can still be verified to be individual from the valid set and this could be used with a drop list

Also encrypted random of course using similar logic where the random function is applied to the encrypted state so such and such I don’t know much about this sorry

Although this increases usage I thinks paths should be more configurable for example maybe up to 5 mix nodes instead of 3 maybe 7 if there is a minimal risk of end to end correlation based on above average delays or lower random range or average if needed I.e peer to peer nym connection to service provider might not have this same problem since it’s not reaching the open internet so the sp would have to be malicious

This would mean users flooding the network and saving their path data intentionally (nsa ddos) or unintentionally (windows user) can not use that data or lose that data and have it used for deanonymization of packets this would at least reduce it to mostly intentional since the entrance node would have to be breaching contract and logging and this would have a much lower impact of the privacy of nym users since currently windows telemetry stores invasive info and could easy be packaged to store nym middle path data

Along with that although for double vpn and bridge users it should still be optional and there should be a functionality were the exit node has some extra entrance node functionality where is closer to a more persistent session optionally some circumstances make sense like port forwarding or client ids being served at the exit gateway

Along with that port forwarding is a major feature of existing vpns that a dedicated minority relies on and talks about a changes provider as a result and due to the decentralized nature of nym vpn there is less of a concern of law enforcement / isp threats and not every node needs to support it

Also client ids being served at the exit gateway and a signed index (signedbyiqjebdd_valid.nymnotonion) and a simple way of contacting client ids via domain or clientid:// (i.e clientid_QWkejbrfb.nymcid) and the signed one can be used to sign multiple client ids witch is a leg up against tor where you will find services have 10s sometimes 100s of unnecessary pieces of critical data (signing keys and only a few need to be stolen for let’s say a phishing attack) and we have hidden services witch grants nym another fraction of the privacy community
And we could then have the signed resolver not just have multiple valid client ids it doesn’t need to run on the same server and can be maybe signed by another key or what not in cold storage
Another thing with this custom vanity domains sold on nym chain burning tokens/benefiting nym foundation/ benefiting node operators but truly benefiting users and with that resolve you might get a couple tor devs/powerful power users on board who don’t want to drown in a cell on that sinking ship

What goes along with that and that is blind client ids using a trusted setup and peer to peer blind paths where neither client / server knows the mixnode path I.e shared blind secret surb this also removes the need for exit gateways except for establishing connections so I could run on Amazon vps and they only know what I’m running not how I’m serving except an entrance node that can be over a bridge applying the same principle then packing junk in like a web rtc server and I’m using snowflake makes a very powerful setup then just add obfuscation however possible

Another thing more in line with the separate entrance and exit connections and blind paths but less similar is a local nym vpn firewall config a just works solution is already possible via whatever and just needs to be setup as a script and could fix the kill switch problem and make it easier for droplists and dns support as in supporting dns itself

Less in line with that post quantum transport security (just works (for now at least)) as opposed to the client making 5 (or even 2) pq connections where the client does aes 256 maybe hybrid with other ones if we’re that concerned and then kyber or what not encapsulation that have the nodes have there own kyber encapsulated keys to communicate with each other and for weak nodes there can unidealy extremely discouraged but we need nodes, to save cpu and ram re-use keys then it could be rotated using the previous path periodically and what not, making the network something I would genuinely feel comfortable staying in for a long time of course we need possibly even more tunnel post quantum but that is an easier to implement start that just needs a firewall and a post quantum vpn/proxy with a long connection span then keep alive adds to the noise

Nym really needs the last one the other ones can wait or be done manually I can’t make my connection unable to be mined in what is assumed to be less than 10 years and I would be very surprised if dpi logs of nym are not being taken although the logging authorities might be angry because it might appear as opposed to one big connection several hundred connections in a second occupying there precious disk space now we just need port agnostic (anger path fight back waste adversary resources except bridges and maybe it’s better but harder to setup for some people I.e residential mix nodes)and or reduced port setups (easier more inclusive less annoying) same client and mix port boosts gateway privacy slightly and for users running services on their node server but so would port agnostic

Another thing sort of in line with the prior is private ip ranges with pluggable transport’s (for mixnodes that trust each other and have ip spaces bigger than the node/s they can/run) so let’s say ipv6 I have 1024 IPs I can give a private one to each node (increases local adversary difficulty sort of with ta if we’re sending over different protocols great for gateways different ip in / out) this can with hidden services be used to have private mixnodes that would cause trouble like the few isps that respect the privacy of their users this assumes data centers are more private but I can always have a fiber optic cable running to by neighbors house so this enabled much more decentralized nym

If this was all implemented I don’t thing any currently available network level privacy/anonymity solution (this is probably better than what closed source criminals use) and you can’t have ano(nym)ity without nym and ano is a double negative!

Thanks for the extensive feedback, let us get back to you point by point.

Thanks a lot for all the thoughtful points!

  • Separate Entrance & Exit Paths – Perhaps I misunderstood, but currently, with the gateway selection in the app, users can already choose both entry and exit nodes (in both VPN and mixnet modes). This means they can stick with the same entry node and rotate only the exit node. Or did you mean at the code level—avoiding the need to regenerate the entire connection when only the exit node changes? If so, that’s definitely something we’re currently working on.

  • Persistent Entrance Node for Validators – That’s an interesting idea! We’ll definitely keep it in mind.

  • Configurable Path Length – This isn’t a trivial configuration change. The Nym network is intentionally designed with three layers of mix nodes in a stratified topology. Supporting longer paths would require a redesign of the topology. While longer paths can reduce the risk of an adversary controlling all nodes in a route, they don’t significantly increase entropy (i.e., anonymity) after 3 hops.

  • Hidden Services – We’re not currently planning to support hidden services, but that could change in the future.

  • Post-Quantum Transport – Yes, post-quantum security is on our roadmap and something we’re actively working toward integrating into the Nym network. You can read more about it in this blog post: nym.com/blog/nym-post-quantum-roadmap. This year, we’re focusing in particular on PQ-KEM.

Thanks again for all the suggestions—we really appreciate them and will definitely take them into account!

1 Like