You are here

About GNUnet

GNUnet is an alternative network stack for building secure, decentralized and privacy-preserving distributed applications. Our goal is to replace the old insecure Internet protocol stack. Starting from an application for secure publication of files, it has grown to include all kinds of basic protocol components and applications towards the creation of a GNU internet.

GNUnet is an official GNU package. GNUnet can be downloaded from GNU and the GNU mirrors.

Read more Friday, February 19, 2010 - 22:34 Christian Grothoff

GNU Summer of Code 2017

This year GNUnet is participating again in the GNU Summer of Code.

If you have any questions or another project proposal, send a mail to the gnunet-developers list.

Project proposals:

Rust APIs for GNUnet services

There are a variety of GNUNet APIs that should be exposed in the Rust wrappers. Implementing these will require extending the port of GNUNet utils written by Andrew Cann and Kelong Cong.

As an introduction to the code base, we suggest that the student and Jeff Burdges together update the asynchronous IO system from gjio to futures-rs or another layer built upon it. Jeff Burdges is expected to concurrently be implementing a GNUNet API for his own mix network work.

Mentors: Jeff Burdges

Required Skills: Rust

Difficulty level: low

Tor compatibility for GNUnet

Implement the AnycastExit spec to enable GNUnet clients to connect over Tor.

Mentor: Jeff Burdges

Note: There was a Special TLDs spec to allow Tor to resolve domain names using GNS over Tor too, but currently that's on hold until folks think more about how names should be moved around the local system. We're calling this more collaborative approach NSS2 for now.

Required Skills: C

Difficulty level: medium

Android compatibility for GNUnet

Implement rudimentary Android compatibility for GNUnet, in part by porting the GNUnet utils scheduler to act as a thin wrapper over libuv.

Mentors: Jeff Burdges and Christian Grothoff

Implementation of a replacement for PANDA

Implementation of a replacement for PANDA (see Pond) with better security, and maybe integration with the GNU Name System for key exchange.

Mentor: Jeff Burdges

Required Skills: Rust or C, crypto

Difficulty level: high

GNUnet Web-based User Interface

Implementation of a Web-based UI for GNUnet similar to GNUnet-Gtk with a yet to be determined framework such as Angular2. This includes the design and implementation of not yet existing REST APIs that expose the GNUnet API.

Mentor: Martin Schanzenbach

Required Skills: C, JavaScript, CSS

Difficulty level: medium

secushare: Implement social networking features on top of pubsub channels

Implement different place types and file sharing by creating a new place for the shared content.

Place types to be implemented:

  • File: generic file with comments
  • Image: display an image with comments referencing a region of the image
  • Sound: play a sound file with comments referencing a timestamp
  • Directory/Album: pointers to File / Image / Sound places
  • Event: with RSVP
  • Survey: ask your social neighborhood questions in a structured form

Also provide the following UI functionality:

  • Fork existing channels, reorganize people into new chatrooms or channels.
  • Share a post (edit and repost something elsewhere, on a fan page for example).
  • Edit a previously published post + offer edit history to readers.
  • Control expiry of channel history.

See also http://secushare.org/features

Mentors: lynX

Required Skills: C/C++

Difficulty level: high

secushare: Implement a Social Graph API for contact adoption and more

Implement aggregation of distributed state from various channels
in order to provide for a powerful social graph API capable of
producing social network profiles, dashboards, a calendar out of
upcoming event invitations (if available), social search functionality
and most of all to make it easy for users to adopt cryptographic
identities of their contacts/friends simply by finding them in the
social graph of their existing contacts ("This is Linda. You have 11
contacts in common with her. [ADD]").

Related to http://secushare.org/rendezvous

Mentors: lynX, t3sserakt

Required Skills: C

Difficulty level: high

secushare: Implement integration with traditional e-mail

  • Emulate IMAP/SMTP protocols as necessary to transform traditional mail clients into secushare user interfaces.
  • Think of ways to map e-mail addresses to secushare identities.
  • Encode or translate various e-mail features into secushare equivalents.
  • Parts of secushare are currently written in Rust, therefore Rust is preferred for this task but it is not an requirement.

Mentors: t3sserakt, lynX

Required Skills: C

Difficulty level: high

GNUnet auction

Implementation of the GNUnet auction system described in
Chapter 3 of this thesis. Specific tasks are adding smart contract creation and round time enforcement to libbrandt as well as creating the GNUnet auction service, library and the three user interface programs create, info and join.

Mentors: mate, cg

Required Skills: C

Difficulty level: medium

Read more Wednesday, March 1, 2017 - 22:18 Christian Grothoff

gnurl 7.53.1 released

Today the microfork of cURL, gnURL, has been released in version 7.53.1 following the last two patch- and version-releases of curl. This fixes fixes CVE-2017-2629 among other issues (see https://curl.haxx.se/changes.html for the full Changelog).

You have to run "./buildconf" before compiling gnurl.

The download is available as usual at https://gnunet.org/gnurl

The tarballs (bzip2 and zip) of this version has been signed with two keys:
my ECC signing key and my RSA signing key (PGP).
If you need the RSA version of the signature, you have to rename the file which contains the ending ".rsa_.sig" to end with ".sig".
There's a known incompability between old and new GnuPG versions and keys, the signature is valid. In case you encounter errors during verification try: 1) ask more keyservers to update their version, 2) update your version of GnuPG and their dependencies.

The two keys are not on any keyservers and can be found attached to this post.
If you don't like this action, get in touch via the developers mailinglist and propose a change to me.

ECC:
pub ed25519/0xCB9C29894A003FBB 2017-01-08
Key fingerprint = 81CB 20AA 4F25 5CDB AC6C 9F72 CB9C 2989 4A00 3FBB

RSA:
pub rsa4096/0xE48786F93EF21B5A 2017-01-08
Key fingerprint = E675 211A 9F41 048B 2D36 A3EF E487 86F9 3EF2 1B5A

Read more Friday, February 24, 2017 - 14:22 ng0

gnurl 7.52.1 released

Today the microfork of curl, gnurl, has been released in version 7.52.1 following the release of curl. This fixes CVE-2016-9594 present only in the previous version of cURL (and therefore gnurl).

Read more Friday, December 23, 2016 - 11:02 ng0

gnurl 7.52.0 released

Today the microfork of curl, gnurl, has been released in version 7.52.0 following the release of curl.

Read more Wednesday, December 21, 2016 - 16:19 ng0

GNUnet e.V. meeting @ 33C3

We are happy to announce our annual GNUnet e.V. meeting at 33C3. All members of GNUnet e.V. are cordially invited.

The meeting starts at 2016/12/28 12:30 at Hall A.1.

More information is available on:
https://events.ccc.de/congress/2016/wiki/Session:GNUNet_e.V._meeting
Information about the venue can be found on:
https://events.ccc.de/congress/2016/wiki/Room:Hall_A.1

Looking forward to see you all!

Read more Friday, December 16, 2016 - 09:44 Matthias Wachs

YBTI / We Fix the Net session at 33c3

At 33c3 the GNUNet & pEp assembly will host a "YBTI/We Fix the Net" session with a series of talks of developing secure alternatives to current internet protocols. We might hold an organized discussion or panel as well.

More details will be posted here closer to the congress. For now, please contact us at wefixthenet@gnunet.org if you would like to present your work or wish to organize a panel or other activity.

We will maintain the schedule in the 33c3 wiki at
https://events.ccc.de/congress/2016/wiki/Session:We_Fix_the_Net .

Read more Tuesday, November 22, 2016 - 14:22 Jeff Burdges

Reverse lookups in GNS

Motivation
DNS allows to resolve the name of an IP address. This is sometimes called "reverse lookup". In fact, it is actually "normal" resolution of a PTR record. The name of such a record would be, for example, 4.4.8.8.in-addr.arpa. The .arpa TLD is managed by IANA.

This blogpost is meant to spread ideas that have been exchanged via private email and might be interesting for a broader audience. If you feel like you have useful comments, don't hesitate to do so.

Reverse resolution is a useful feature to enhance readability of service descriptors.
Examples where reverse lookups are useful include:
Received an email from bob@ABCD.zkey or pubkey authentication by ABCD.zkey to my service.
In GNS, reverse resolution is currently not supported and even if it was, there are some obstacles that need to be managed.

Reverse lookups in GNS
GNS names (.gnu TLD) are resolved relative the the user's local root zone. GNS reverse lookups are limited to PKEYs. e.g. Alice wants to know who ABCD.zkey is and how her root namespace relates to that identity.

A simple example reverse lookup would be:

$ gnunet-gns -R ABCD.zkey
Result: dave.bob.gnu

This tells alice that ABCD.zkey is actually "dave" that is known by Alice's friend "bob".
However, the actual lookup of this delegation is non-trivial in GNS as bob can choose any name for dave's PKEY. This name is unknown to Alice.
A straight forward approach for a lookup would be the following:

  1. Alice check's her local root namespace for a delegation record (PKEY) with label "name" that contains ABCD
    1. If a record is found, stop and return name.gnu
    2. else continue with 2.
  2. Alice performs a GNS lookup for the NICKname of ABCD resulting in a result "nick"
  3. Alice checks if one of the zones she delegates to contain a PKEY record with name "nick" and value ABDC
  4. If a result is found as a delegation to dave.delegation.gnu the result is returned
  5. Else resolution stops

Why does resultion stop at 5.? Because if Alice cannot find a delegation to ABCD in one of her known and delegated PKEYs there is no way for her to enumerate all records in those namespaces (by design, GNS leverages this for query privacy and record confidentiality).
This method is characterized by two properties:

  • The resolution direction is "forward", i.e. lookup starts at the root zone and not at the target zone
  • The algorithm tries to "guess" likely chosen names (NICKs) to resolve 3rd party delegation
  • Without some additional meta information, reverse lookups are limited to two hops, e.g. dave.bob.gnu is possible, dave.carol.bob.gnu is not

Advanced reverse lookups in GNS
In some discussions with Christian we have established a few approches that can improve reverse resolution.

REVERSE records
If namespaces would contain special records under the "+" label that point back to other namespaces delegating to them it would allow us to implement an algorithm to lookup the delegation "backwards", i.e. starting from the zone in question (ABCD):

  1. Alice resolves "+" REVERSE records in ABCD, if not existant resolution fails
  2. For each entry e_n in the REVERSE record set, Alice checks if she has a delegation to that PKEY in her master zone, return chain if true
  3. Repeat 2 until found or a certain theshold/limit of recursions is reached and return error

This approach requires the addition and management of REVERSE records. As this cannot be expected by the user it must be done by GNS automatically. For example, GNS might periodically check if any namespaces delegated to from the root zone also contain a delegation back to our root zone (e.g. by checking if alice.bob.gnu can be resolved to Alice's root zone). Those namespaces are added in a REVERSE record.

  • The resolution direction is "backward", i.e. lookup starts at the target zone and not at the root zone
  • The algorithm relies on correct mappings in REVERSE record and the usage of likely chosen names (NICKs) to resolve 3rd party delegation
  • It supports any length of delegations

REVERSE and FORWARD records
We could also support some kind of directed
search from both ends:

  1. The "+" record set contains a special record with
    a list of PKEY delegations that I'm aware of (REVERSE)
  2. The "+" record can similarly contain a list of public
    labels of PKEY records that I delegate to (FORWARD)

Now, if we want to find out who ABCD.zkey is, we start from both ends:

  1. Match REVERSE of ABCD.zkey against all of my names/delegations; if not found: 2
  2. Download zones below all of my names; see if they match those found in previous step
  3. Get FORWARDS of zones from 2; match against ABCD and ABCD's REVERSEs
  4. continue collecting FORWARDS and REVERSE and matching them

Each of the iterations results in an exponential increase in the
working sets, so we shoud stop at some maximum number of records inspected with "not found".

  • The resolution direction is "forward" AND "backward", i.e. lookup starts at the target zone and at the root zone
  • The algorithm does not rely on correct mappings in REVERSE records and the usage of likely chosen names (NICKs) to resolve 3rd party delegation
  • It supports any length of delegations
  • It _might_ be a time improvement over only REVERSE "backward" resolution by trading it for state space
  • EDIT: One other thing is that this approach improves resolution success in cases where no complete REVERSE chain exists

Global delegation DB
If we add a way to distribute the public
delegations, for which something simple like running a combination of
gossip (new public record) and the existing GNUnet SET union protocol
(new neighbour) between peers should allow us to easily replicate the
entire public DB globally. Then, reverse lookup is trivial (local
DB operation), at least as long as all public links can be globally
replicated. Might combine it with some modest proof-of-work to avoid
people spamming the network.
This might also require us to redefine record visibility to:

  • private: (as in private in GNS right now, or local signature in
    GnuPG):
    only I can use them
  • public: (as in GnuPG Web-of-trust):
    everybody can see that X has delegated name Y to key Z
  • default: (as in GNS non-private / GNS default):
    the records are stored encrypted/obfuscated in a DHT, if you know
    the zone and label, you can get and decode them
  • Aka "Too boring and too inefficient"[sic]
Read more Friday, October 7, 2016 - 09:16 Martin Schanzenbach

GNUnet for Gentoo

In summer 2015 I started to package GNUnet for Gentoo as contributor to the youbroketheinternet-overlay.

This short post is to announce that, among other packages, you can now build and install GNUnet (and gnunet-gtk, gnurl) on Gentoo as easy as:

Read more Sunday, October 2, 2016 - 23:16 ng0

Pages

Subscribe to Front page feed