There's a (slightly hidden) public network called "Earth" with ID 8056c2e21c000001, discovered a few interesting hosts already (by using non-intrusive avahi-browse):
28.204.184.27:6667 - IRC server identifying as "nagisa.yasashiisyndicate.org"
There's also a couple o' macbooks and, for a few minutes, someone advertised their EPSON L110 Series printer but it vanished as quickly as it emerged. :)
So far I love it, seems like a viable replacement for Hamachi/Tunngle, the Windows Client is rather ugly but functional, had no issues on Arch Linux (built from source). Kudos.
Earth is slightly hidden because it's an experimental feature, but way back when I started the project it was the point.
I found that most users wanted private networks, so I added network IDs and certificates of authorization. But I still wanted to maintain the original vision in there somewhere.
RFC1918 will likely not work since NAT'd users will be using ZeroTier. But there is a solution to this EXACT problem. RFC6598! http://tools.ietf.org/html/rfc6598
I think they could safely use 100.64.0.0/10 -- It's arguably designed for this kind of thing.
I'll give you 10 peers, each on its own RFC1918 subnet. You give me a flat addressing scheme that doesn't involve NAT and IP6, requires no manual configuration on peers' part and keeps them on a single connected (in routing terms) network, so that broadcasts and multicasts work. Go!
I'm the author and I'll take that as a complement... I think.
My take on really slick polished valley hipster corporate pr is if you've got the resources to pull that off, sure, do it.
But if you don't it's like a bad special effect in a movie, usually worse than no special effects at all. As they say in that field if you don't have the flash it's all gotta be in the script.
I'm not clear what you're trying to say with that last sentence. I didn't look carefully (beyond the reference to NaCL) but I assume this is using Salsa20 keyed by Curve25519. Neither of those algorithms are any more "exhaustible" (to coin a term) than AES or static DH, both of which are obviously capable of providing security in normal situations more or less indefinitely.
I assume you must be referring to something other than the security longevity of a Salsa20 key.
Sorry, I was just copy/pasting from the FAQ so you'd have more context (not the OP nor the developer of ZT). I don't know enough to know what the difference between "round structure" and "20 rounds of mixing"[1] is, but I'd love to find out. Are there better references than that wiki page?
They define a core transform, which nonlinearly combines key material with plaintext on a bit-by-bit basis and provides "confusion" and "diffusion".
You can think of modern cipher design as analogous to RISC computers. A designer has a choice: they can make a very strong transform function, or they can make a very simple transform which is weak by itself, but strong when repeated. The latter approach dominates modern cipher design.
Modern ciphers execute the transform (the "round function") many times. They take a key and expand it into subkeys, then use those subkeys with successive invocations of the round function, feeding the (gradually strengthening) ciphertext back through the cipher each time.
Curve25519 and ed25519 aren't ciphers. They are two different ways to use elliptic curve math in cryptography; the former implements Diffie Hellman key agreement in the mathematical domain of a specific secure curve, and the latter implements public key signatures in that same domain. Neither mechanism is suitable for encrypting data; they're used as tools to get two parties to agree to a cipher key to use to encrypt the actual data.
In TLS, for instance, Curve25519 might negotiate an ephemeral key between the server and the client (so that nothing would persist to disk that could be scooped up by NSA later and used to decrypt the session when it ends). Something like ed25519 could be used to sign the key exchange to make it impossible to MITM the session. The ephemeral key would get plugged into Salsa20, which would perform the actual encryption. It's Salsa20 that has the round structure.
Salsa20 wants 20 rounds, but the last 8 of those rounds are for extra security; the author believes it to be secure at 12 rounds, and nobody has disproved that, or has any reason to believe he's wrong. Salsa20 was designed for performance, and the cost of Salsa20 rounds is low, so 20 rounds was a pragmatic, cheap hardening mechanism.
On the other hand, the performance difference between reduced-round Salsa20 and real Salsa20 isn't significant, so that was indeed a goofy choice† on their part. Salsa20 is very, very fast. Not to mention: bulk crypto in general --- AES in CTR mode, for instance --- is also very fast.
I'm not sticking up for this particular project; just reacting to the idea that NaCL would need to be rekeyed frequently.
† (I'm taking it on faith that they actually are using Salsa20/12; I didn't look carefully.)
You can use Curve25519 as a cipher. It's just fairly slow, like all PKC. It's something like 600k cycles for 32 bytes, while AES is around 30 cycles for 8 bytes.
Maybe in some high-throughput application, or something under hard performance constraints. IIRC VMWare uses Salsa20/12 for its remote desktop encryption thing.
20 rounds gives a more comfortable security margin, though, so it's a default that lets you sleep well at night. That said, an attack that convincingly broke 12 rounds could be enough to start thinking of switching to something else.
This is painfully close to something that could be much better. Sadly this "p2p" system is strongly centralized. I cannot make a private network without zero-tier's authorization. I cannot add nodes to a private network without zero-tier's authorization. If zero-tier servers fail or the company dies, the network goes with it. Because the strong centralization, future viability of the network hinges on a single small companies continued existence. I cannot use this to build anything meaningful. It could only serve as a competitor to other vpn providers, not an improvement over the status quo.
It's almost completely open source[1]. The only component that isn't open is the web interface itself, but there's complete documentation on the internal data structures, how to run a super node, and how to reconfigure the clients to serve up those super nodes instead of the ZT-provided ones.
I rather happy about that, it saves me a lot of work. I've already cloned the repo on github (and a few local machines). Essentially I currently plan on unwrapping their administration system and switching to a shared secret model.
It was a breeze to set up.
I've been using it as a VPN to connect all my boxes and ssh to my machines that are behind NAT, and it's been very reliable.
And, if I want, I can connect my boxes to the big cjdns mesh network "Hyperboria" and do my part for promoting a decentralized internet.
I really like CJDNS, but it is more suitable to run on real routers than to use for virtual networking. Its overlay network and routing does not take into account real latency or congestion of the rest of the internet.
Look at the netconf-master/ subfolder -- you can make private networks without using the web UI. But it's hard right now. It'll probably be made easier in the future.
As far as pure decentralization goes: that's very hard, much harder than NAT-t and cryptography. I've prioritized zero-configuration instant-on and performance because that's what 95% of users want.
Yep. It pulls the actual config from a Redis database.
A 16-digit (64-bit) network ID consists of two parts: the 40-bit ZeroTier address of the node responsible for serving network configuration to members, and an arbitrary 24-bit network ID. When you join a network it just queries the netconf master for the network configuration. It's pretty simple. That's why all the network IDs you create at zerotier.com right now begin with the same 10-digit hexadecimal number. That's the ID of the node responsible for them and there's only one right now (though it's set up to fail over to another server, so it is fault tolerant).
BTW... network configuration servers can go down and networks will keep working. You just can't change their configuration. So it's also fault tolerant in that way.
I tried this it's really really simple to set up (than openvpn tinc etc). However NAT traversing is still a hard problem and I cannot get online behind two NATs.
It's more or less the same underlying approach as Hamachi: L2 virtualization. The execution is a bit different, and it's designed to be more sysadmin-friendly to enable its use as something like a cloud backplane network.
As far as the future goes, I have different and I think broader goals. VPN is just the first application. I have others in mind.
Right now it's charging for the convenience of setup and administration on zerotier.com. You can run your own "netconf master" and create your own networks, but it requires some system administration and Redis database wrangling.
Generally the people who will pay you are the people who want convenience, like business users, and the rest are people who won't ever pay you anyway.
The supernodes are not part of the business model. That architecture just exists to make the system fast and secure by providing managed anchor points. All traffic is end-to-end encrypted so the supernodes can't see traffic content.
Most of the time, no. The first packet of a given connection will hit a supernode (one of four machines run by ZeroTier) to open up the NAT ports, but after that everything is point to point.
Except in the case of an overly restrictive firewall that doesn't allow outgoing UDP on port 9993, in which case every packet is tunneled over port 443 through one of the supernodes.
That said, every packet is encrypted with NaCL so that situation is less concerning. Just slower.
28.204.184.27:6667 - IRC server identifying as "nagisa.yasashiisyndicate.org"
There's also a couple o' macbooks and, for a few minutes, someone advertised their EPSON L110 Series printer but it vanished as quickly as it emerged. :)
So far I love it, seems like a viable replacement for Hamachi/Tunngle, the Windows Client is rather ugly but functional, had no issues on Arch Linux (built from source). Kudos.