Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] CJDNS hype

Gregory Maxwell greg at
Sun Jul 14 11:45:02 PDT 2013

On Sat, Jul 13, 2013 at 12:36 PM, Mitar <mmitar at> wrote:
> Hi!
> I am a bit concerned with the CJDNS hype I am observing around. I do
> like that decentralized Internet is getting momentum, but I am
> concerned if CJDNS is really the way to achieve that. From its
> whitepaper it seems that it is susceptible to a Sybil attack:

After this thread started I wrote to the author— as I'd pointed out
before I had the same concerns initially but had spoken to him and
basically came away with an impression that he was aware of the
problem space and wasn't doing the dumbest possible thing as a result—
and there was at least a fighting chance that the system addressed the
issue, but I didn't care (or, really, have time) to understand more at
the time, so I couldn't write an actual explanation.

He seems to be having some problems getting onto the list, so he sent
me a response to reflect up to it:

----- CUT HERE -----

The answer to ID clustering attacks is that cjdns is just really lazy,
it routes to the physically nearest node whose ip address is numerically
closer to the destination than your own (based on KAD).
Since the physical topology is friend-to-friend, the attacker is forced
to have a relatively tight cluster of nodes in physical space, they can
pollute their own neighborhood but not the whole network. Pollution of
one physical neighborhood would likely lead to them being de-peered by
their "friend" who gave them the link.

Re the recursive routing, it has two options. You can send direct to the
destination at the switch level or you can forward to any node in the
network and ask them to forward to the destination. The nodes between you
and the one you asked to forward will have no access to the IPv6 dest
address and if the one you are forwarding to us unfriendly, you use
someone else. We've considered changing this to improve scalability
but I can't figure out how to preserve this guarantee.

The most scary general attack on the idea is a node who drops 10% of the
packets sent through them. I don't know how to detect it statelessly and
they can do quite a bit of damage.
Again though the physical reality of the network comes in to play.
The nodes which carry the majority of the traffic are heavily peered core
nodes and the operators of such are unlikely to intentionally attack the
network, this is the same logic which holds BGP together despite it's
painful frailty.

Hope that helps


More information about the liberationtech mailing list