[cryptography] cjdns review
guus at sliepen.org
Thu Oct 4 16:45:42 EDT 2012
On Thu, Oct 04, 2012 at 02:37:53PM +0200, Eugen Leitl wrote:
> I've recently become interested in cjdns http://en.wikipedia.org/wiki/Cjdns
> which apparently used NaCl in UDP over tun when tunneling.
> I'm not aware of any review of the entire system, including
> key generation etc.
Disclaimer: I only read the Wikipedia article and the whitepaper.
It is very interesting, they use the hash of a public key as the address of a
node. That reminds me of SILC. There is some cost involved in claiming an
address; one must generate 128 EC keys one average, since the first byte of the
address must always be 0xFC in order to be a valid IPv6 address without
conflicting with public addresses.
If you know which node you want to talk to, both peers first generate ephemeral
keys, which are signed and encrypted using NaCl's crypto_box() function. Then
these ephemeral keys will be used to encrypt the real data packets, but again
using crypto_box(). That means asymmetric crypto is used for every packet,
which makes it VERY slow.
Not only that; apart from end-to-end encryption and authentication, packets are
also encrypt+authenticed hop-by-hop (unless the peers are direct neighbors).
Given that it is also possible to do a limited form of source routing, this
might make it robust against traffic analysis and increase anonimity, but it
adds a large burden to intermediate nodes. It also goes against the Internet's
principle of a dumb core with smart edges.
I do not see an obvious flaw in the key generation, encryption and
authentication. But in the end, you are not going to remember 120 bit
addresses, so currently they are just running DNS on top, I guess that is a
very weak point in cjdns.
Another issue might be the routing table itself; the whitepaper doesn't mention
much, but the Wikipedia page say they use a DHT similar to Kademlia. I do not
know how well that can route around "damage" or malicious nodes.
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus at sliepen.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: Digital signature
More information about the cryptography