Cjdns
 | |
| Original author(s) | Caleb James DeLisle (cjdelisle) |
|---|---|
| Stable release | 17.1 |
| Development status | Active (alpha software) |
| Written in | C |
| Operating system | Linux, OS X, Windows, FreeBSD, Illumos |
| Platform | x86, amd64, MIPS, ARM, PowerPC[1] |
| Size | 1-3MB |
| Type | VPN, peer-to-peer, router |
| License | GPLv3 |
| Website | https://github.com/cjdelisle/cjdns |
Cjdns is a networking protocol, a system of digital rules for message exchange between computers. The philosophy behind cjdns is that networks should be easy to set up, protocols should scale up smoothly and security should be ubiquitous.
Cjdns implements an encrypted IPv6 network using public key cryptography for network address allocation and a distributed hash table for routing. The New Scientist reports that "Instead of letting other computers connect to you through a shared IP address which anyone can use, cjdns only lets computers talk to one [another] after they have verified each other cryptographically. That means there is no way anyone can be intercepting your traffic."[2]
Interface
The cjdns program talks to other programs on the computer through a TUN device which the computer sees as a regular network interface that accepts IP datagrams. Any program that uses IPv6 can communicate in a cjdns-based network without any modification.
Address Generation
Cjdns addresses are the first 16 bytes (128 bits) of the double SHA-512 of the public key. All addresses must begin with the byte 0xFC, which in IPv6 resolution, is a private address (so there is no collision with any external Internet addresses).
The address is generated initially when a node is set up, through a brute-forced key generation process (keys are repeatedly generated until the result of double SHA-512 begins with 0xFC). This process is unique, as it guarantees cryptographically bound addresses (the double SHA-512 of the public key), sourced from random data (private key is random data, public key is the scalar multiplication of this data).
Internals
The routing engine stores its routing table in a distributed hash table similar to Kademlia.[3] When forwarding a packet, rather than looking up an entry using the traditional Kademlia approach of asking a node whose id is similar to that of the target, cjdns forwards the packet to that node for further processing.[3] In order to allow a node to be in touch with many nodes despite being directly connected only to as few as one, there is a switch layer which underlies the routing layer. The switch is inspired by MPLS protocol but without the universal uniqueness nor longevity of MPLS labels but instead with added ability to determine the source of an incoming packet from its label and ability to determine whether a given node is part of the path represented by a label, and ability to switch a label without any memory lookups. In the most simple terms: a switch label is like driving directions to a destination.
It is designed so that every node is equal; there is no hierarchy or edge routing. Rather than assigning addresses based on topology, all cjdns IPv6 addresses are within the FC00::/8 Unique local address space (keys which do not hash to addresses starting with 'FC' are discarded).[4] Although nodes are identified with IPv6 addresses, cjdns does not depend upon having IPv6. Currently, each node may be connected to a few other nodes by manually configuring links over an IPv4 network (the Internet). The ultimate goal is to have every node connected directly by physical means; be it wire, optical cable or radio waves.
A CryptoAuth session between two given nodes is set up with a two-packet handshake. Each of the two packets contains the permanent and temporary keys of the sending node which are piggybacked on top of normal data packets. The data in those packets is encrypted using the permanent keys. Once the temporary keys have been exchanged, the permanent keys are no longer used in that session and the temporary keys are discarded when the session ends so that the data sent during that session cannot be decrypted later.[5] Since the handshake is piggybacked on top of the first two packets, the maximum allowable packet size differs from packet to packet but the encryption is set up without introducing lag to the application.
Routing
Routing is designed such that each packet requires very little handling by an individual router, or node. Each node will respond to 'search queries' asking it for other nodes nearby to it. This allows the sending node to determine and add routes to its own routing table.[3] Once the sending node has determined a route, it sends its packet to the first node on said route. For each hop, the receiving node reads the packet's header to determine where to next send the packet. Before the packet is forwarded to the next hop, the node performs a bit shift on the packet's headers, making it ready for use by the next node.[6]
Security
The belief that security should be ubiquitous and unintrusive like air is part of the core philosophy behind cjdns. The routing engine runs in user space and is compiled by default with stack-smashing protection, position-independent code, non-executable stack, and remapping of the global offset table as read-only (relro). The code also relies on an ad-hoc sandboxing feature based on setting the resource limit for open files to zero, on many systems this serves block access to any new file descriptors, severely limiting the code's ability to interact with the system around it.[7]
On the other hand, some expressed concerns regarding security and performance of cjdns' routing.[8] Because cjdns routing is based loosely on Kademlia, it retains its well known security issues, like a Sybil attack. This means a denial-of-service attack could be launched against the network which could as a consequence lead to service interruption and censorship. The cjdns protocol attempts to address these concerns[9] with an approach similar to Virtual Ring Routing.[10]
Development
Development discussion goes on in the #cjdns IRC channel on the EFnet IRC network, that network having been chosen because of its decentralized control structure (a mirror of the cjdns security model).[11] Caleb James DeLisle maintains Benevolent Dictator for Life status over the project. The cjdns GitHub repository is used for source code hosting and as a bug tracker.
Distribution
Cjdns employs a rolling release style model because the protocols and algorithms are new inventions and the way they behave in the real world is still not well understood.[12] Users can clone the git repository containing the source code and run a shell script which compiles the source code and runs unit tests.
Cjdns is available on most UNIX-like systems like Linux (Debian, Ubuntu, etc.), Mac OS X, Illumos and FreeBSD. A wide variety of architectures are supported, most notably x86, x86-64, PowerPC and MIPS. This allows users the flexibility of using old or new hardware, making it easy to get started with cjdns. There are nodes running on high-end gaming machines, PlayStation 3 and even old OpenWRT-compatible routers.
References
- ↑ http://oscar.ianlevesque.org:8010/waterfall
- ↑ http://www.newscientist.com/article/mg21929294.500-meshnet-activists-rebuilding-the-internet-from-scratch.html
- 1 2 3 https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md#the-router
- ↑ https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md#pulling-it-all-together
- ↑ https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md#the-cryptoauth
- ↑ https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md#the-switch
- ↑ https://github.com/cjdelisle/cjdns/blob/master/util/Security.c
- ↑ http://mail.thefnf.org/pipermail/builders/2012-May/000544.html
- ↑ DeLisle, Caleb James (July 14, 2013). "[liberationtech] CJDNS hype". Retrieved January 25, 2014.
- ↑ http://research.microsoft.com/pubs/75325/virtualring.pdf
- ↑ https://ezcrypt.it/ML4n#ej6rorotmsxq7jF8ViyGjTVh
- ↑ https://github.com/cjdelisle/cjdns#how-close-is-it-to-complete