[messaging] GNU Name System

str4d str4d at i2pmail.org
Sun Oct 5 21:12:46 PDT 2014

Hash: SHA512

David Leon Gil wrote:
> On Sun, Oct 5, 2014 at 5:01 PM, D. J. Bernstein <djb at cr.yp.to> 
> wrote:
>> The traditional view is that maximum-security decentralized 
>> systems can't be usable, so we have to compromise on security, 
>> typically by trusting centralized third parties.
> I very much doubt most people on this list believe that.

DJB's stated traditional view is IMHO reasonable, and reinforced by
the often-abysmal UI/UX associated with these systems. (Fortunately,)
I doubt that the set of people on this list is representative of the
general population.

>> The reason I'm writing now is that I think most people here 
>> haven't yet heard of the GNU Name System, a _usable_ 
>> maximum-security decentralized naming system:
>> https://gnunet.org/sites/default/files/paper_cans2014_camera_ready.pdf
> Some problems with this paper (which I saw an earlier version of as
> well, I think):
> - Doesn't describe how the DHT will work. The details are critical 
> to security and scalability.

They use R5N [0], see reference 18 in that paper.

> - Doesn't, as best I can tell, provide any way to deal with spam in
> the global namespace. (I.e., spammers, phishers, et hoc genus omnes
> will rapidly register every memorable/short/confusable name.)[*]

Bhere is no global namespace. Rather, the global namespace (*.gnu) is
_always_ owned by the local user. GNS stores domain name zones in the
DHT, but those zones are indexed by the public key of the zone, not by
its desired name. Alice adds Bob's GNS zone to her global namespace as
*.bob.gnu or *.nemesis.gnu at her choice. Bob can suggest a name
within his zone file, as could spammers. But there is no requirement
that those suggestions be unique, and Alice will only fetch the zones
of public keys she has an interest in. The spam issue therefore
reduces to the common issue of DHT pollution.

> I'll note that the query privacy section (section 4) seems to give 
> a decent enough design. But that's really the only part of the 
> paper that is fleshed out enough to bother with. I would, however, 
> be very interested to learn more details about the design.

I have been examining GNS as a possible replacement for the current
petname-only naming system in I2P. Anyone curious can read the
discussion thread [1], or the comparison matrix [2], for insight into
applying GNS to an existing system.


[0] https://gnunet.org/sites/default/files/nss2011.pdf
[1] http://zzz.i2p/topics/1545 (inside I2P)
[2] https://trac.i2p2.de/wiki/GNS



More information about the Messaging mailing list