Title: BASE LAYER

Base Layer

GNUnet is composed of several layers (see Figure 1) and provides itself a transport service which is connectionless and not reliable. The GNUnet base layer relies, in turn, on a transport service of the same quality, which is typically UDP. There are, however, also implementations utilising TCP, HTTP, or SMTP.  

The base functionality of GNUnet is twofold and consists of (a) the exploration of new users and (b) the integrity-preserving, accountable, and confidential communication between users. For that reason, each GNUnet client generates a pair of RSA keys, which will be used as digital identity and for confidential communication simultaneously. The digital identity is propagated to other GNUnet clients while the new client registers. 

In order to become part of the GNUnet network, a client first of all needs to know a subset of addresses belonging to clients who are already part of the network. In case of UDP as underlying transport layer, such addresses would be tuples, each consisting of an IP address and a port. The size of the address subset affects the speed of the registration process. The greater the subset is the faster the new client becomes known to the other clients. The actual process of registration is done by means of HELO messages. The new user then sends a HELO message to each of these addresses together with her own address, validity information, and her public RSA key. Additionally, the HELO message is signed by the client, using its secret RSA key.

Figure 1: Layer model of GNUnet.

Thus, the new user proves that she has control over the secret key. In the next step, the new client tries to exchange a symmetric session key by means of asymmetric encryption with each client who received a HELO message. The session key is used for link encryption between adjoining clients. Additionally, HELO messages of new clients are distributed through the GNUnet network. That way, each client discovers more and more new clients by time. The distribution depends on the clients which received HELO messages. These clients support the distribution by forwarding received HELO messages to random clients. It is then up to the client, who receives new HELO messages, to decide whether an encrypted connection should be established to the originator of the HELO message or not.