ZeroTier: Network Virtualization Everywhere
zerotier.com
zerotier.com
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.
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.
Just... don't.
http://www.dslreports.com/forum/r28371780-Why-is-my-internet...
http://android.stackexchange.com/questions/11388/are-tmobile...
I think they could safely use 100.64.0.0/10 -- It's arguably designed for this kind of thing.
Let's hear the alternatives.
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!
Peer 1: 192.168.0.111/16
Peer 2: 172.16.0.222/12
Peer 3: 10.0.0.333/8And maybe I thought the State of NAT posting was pretty good.
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.
* Private backhaul network for my VPSs, useful for things like ssh, deploys, monitoring, metrics, and log aggregation
* Private network that I can set up between my laptop and my parents' desktop and fix things via VNC without having to pay for a dedicated service.
The lack of perfect forward secrecy is sort of a bummer, but for my purposes it should be fine.
Still uses supernodes, too. May be interesting once it's matured a bit and been redesigned, however.
According to djb (author of these algorithms) you shouldn't really be persisting keys for longer than minutes, let alone indefinitely.
I assume you must be referring to something other than the security longevity of a Salsa20 key.
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.)
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.
Ok, but presumably if the only services I "route" through ZT are encrypted (like ssh, or forward-secure HTTPS) then I don't care, right ?
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.
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.
Here's a personal post I wrote on the difficulty:
http://adamierymenko.com/decentralization-i-want-to-believe/
https://github.com/zerotier/ZeroTierOne/tree/master/netconf-...
?
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.
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.
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.
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.