[HacDC:Byzantium] cjdns review

Mon Nov 26 19:53:38 PST 2012

Not sure if I need to be on that list so I just sent it to you.

On 11/26/2012 11:53 AM, Eugen Leitl wrote:
> ----- Forwarded message from Ben Mendis <ben.mendis at gmail.com> -----
> 
> From: Ben Mendis <ben.mendis at gmail.com>
> Date: Mon, 26 Nov 2012 11:42:23 -0500
> To: Byzantium at hacdc.org
> Subject: Re: [HacDC:Byzantium] cjdns review
> Organization: Antenna House
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
> Reply-To: Byzantium at hacdc.org
> 
> To be specific, I don't think CJDNS is a bad technology. On the
> contrary, I think it is interesting and will have a valuable role in
> influencing then next few decades of the Internet. However it's not a
> replacement for the use cases that Byzantium Linux or Commotion Wireless
> try to address. While most of the CJDNS fanboys will try to tell you
> that CJDNS can replace Layer-3 routing (and they're not completely
> wrong) the problem is that it's not a practical alternative for our
> deployment model.
> 
> Creating connections between nodes in CJDNS requires more collusion in
> that new nodes must know the correct public key and password to create a
> link with another existing node. This is good for security, but not
> conducive to the rapid and organic deployment that we're looking for.
> Furthermore, as a mobile node roams from one AP to the next, they would
> need to re-negotiate the link (and discover key/pw again) with each new AP.

This is true for now, I'm working on a patch to connect nodes on the same
LAN by beaconing out a key/passwd. The UDP/IP4 connector needs security
because otherwise you let the whole internet in.

> 
> If the AP offers up some kind of layer-3 routing to other networks which
> have nodes (such as the Internet) then you don't have the re-negotiation
> problem. However, in our use case Internet access is not a guarantee.
> And what provides for that layer-3 routing anyways? We'll that's exactly
> what Byzantium and Commotion try to solve with OSLR or Babel or BATMAN.
> 
> Furthermore, CJDNS doesn't route IPv4 traffic to the IPv4 Internet, at
> least not by itself. You would need to do some kind of 4-in-6 tunneling.
> Which is yet another layer of overhead and latency, and another "moving
> piece" that can fail and disrupt service for users.

The switch layer will carry whatever you like with 52 bytes of overhead.
IPv4 tunneling over the switch layer is written but unfinished/untested.
https://github.com/cjdelisle/cjdns/tree/master/tunnel

> 
> So based on my understanding of CJDNS, it's not a competing technology
> in our problem domain, although some of the functionality overlaps. And
> in certain cases, they are actually complimentary projects. CJDNS, in
> its typical and most practical deployment, is an overlay network. That
> means it needs an existing network to run on top of, and that's exactly
> what Byzantium or Commotion can provide.
> 
> 
> A couple of other points of interest I've come across.
> 
> Starting with Wikipedia (I know it's not authoritative and often out of
> date).
> " 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)."
> 
> Two things. First of all, wouldn't brute-forcing the key generation
> exhaust the entropy available in /dev/random and force the use of less
> random bits from /dev/urandom? Also, don't the public/private keys need
> to be based on prime numbers, not just random numbers? The strength of
> RSA is the assumption that factorization of large _prime_ numbers is
> mathematically a hard problem to solve. This last part is probably just
> the Wiki-author's misunderstanding. I'm giving cjd the benefit of the
> doubt because he seems like he would know better.

Randomness is really weird.
For example I can brute force a key by taking one random number then
incrementing it by 1 every time after, if the original number is safe
every number thereafter is also safe.
Cjdns gets it's numbers from the libevent arc4 PRNG which is cloned
from the BSD code. I understand this PRNG is also used by TOR.

BTW the libevent arc4 PRNG does seed using dev/urandom, I've never heard
of any solid research on the whole "less random" thing, as long as the
kernel PRNG isn't completely broken, I see no reason why urandom should
be measurably less safe. There seems to be an urban myth about these
"less random" random sources probably perpetuated by the people selling
hardware random generators.

The prime thing is not needed because we're not generating RSA keys,
these are Curve25519 ECC keys which are only good for Diffie Hellman key
agreement and I'm just following the API as specified here:
http://nacl.cr.yp.to/secretbox.html

> 
>>From the projectmeshnet wiki.
> "While you can technically add as many as 255 peers, more is not better.
> The software likes to run with about 3 peers and will work fine even if
> only 1 of them is functioning. ~ CJD"
> 
> A limitation of 255 peers seems arbitrary and actually quite low. I'm
> sure it would be fine for permanent infrastructure nodes, however it
> seems quite restrictive for mobile ad-hoc nodes which might roam in and
> out of range with dozens or hundreds of other nodes.

Nothing in the protocol prevents it, it's just an implementation limit
because nobody has written a number encoding scheme for numbers >255.
Other nodes do not care about your encoding method so this is strictly
an implementation detail.

> 
> I still think CDJNS is a cool project and I'm keeping an eye on it, just
> not for rapid deployment in disaster relief scenarios. The usability

I think this is valid for the moment. Lots of unfinished work.
The 64k$ question is, does it make more sense to hack on current tech
because cjdns isn't there yet or to hack on cjdns because in 3 years, current
tech is going to be outdated.

My answer to that question is obvious but it's a personal decision for everyone.

> cost, while modest compared to alternative overlay networks, is still
> quite high in comparison to the solution we have been building.
> Hypothetically, we could make CJDNS just as automatic, but in the
> process we would be discarding some of the security benefits it's trying
> to achieve.
> 
> No one tool is a panacea for the problems facing the Internet. The use
> cases we are facing today are so diverse that no single solution can
> encompass them all. Projects like CJDNS and Byzantium are successful
> because they focus on solving one chunk of the problem space and doing
> it as well as possible without getting distracted by every shiny use
> case that comes along. We also benefit from adherence to standards and
> best practices that allow us to interoperate with the other projects
> that are solving other chunks of the problem space.

I appreciate the complements, I hope you don't pull punches for my sake.
"Throw it out, it all sucks" is kind of the cjdns motto so when something
in cjdns is broke ass, I want to know so we can decide if we want to change
it and whether that's a protocol break or just an implementation detail
which we can punt off till later.

Thanks,
Caleb

> 
> That's my $0.02.
> 
> Ben the Pyrate
> 
> On 11/26/2012 09:25 AM, Eugen Leitl wrote:
>> Guys, can you give me the beef with what you think
>> is wrong with cjdns' design? Please make sure to
>> look at the latest work, including L2 transport.
>>
>> I'll forward your comments to cjd.
>>
> 
> 
> 
> 
> ----- End forwarded message -----
> 

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE