On 10/4/12 4:45 PM, "Guus Sliepen" <g...@sliepen.org> wrote:
>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. Sounds like HIP <http://datatracker.ietf.org/wg/hip/charter/> >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. Interestingly, that's also a part of HIP <http://tools.ietf.org/html/rfc6537> David > >-- >Met vriendelijke groet / with kind regards, > Guus Sliepen <g...@sliepen.org> _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
