commit 096cef58f2ea23096d6fa3b637951da59b93804b
parent 03c7175c7555081d2199a56f5016abed1f48725e
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 8 Jun 2026 18:51:20 +0200
remove outdated info, add more accurate descriptions on crypto
Diffstat:
| M | about.rst | | | 130 | +++++++++++++++++++++++++++++++++++++++---------------------------------------- |
1 file changed, 64 insertions(+), 66 deletions(-)
diff --git a/about.rst b/about.rst
@@ -189,6 +189,56 @@ In order to realize a peer-to-peer network stack, a subset of GNUnet subsystems
emulate what can be found in the ISO/OSI layer of the Internet.
(TODO insert image here)
+Peer Identities
+~~~~~~~~~~~~~~~
+
+In GNUnet, the identity of a host is its public key called **Peer Identity**.
+For that reason, man-in-the-middle attacks will not break the authentication or
+accounting goals. Essentially, for GNUnet, the IP of the host has
+nothing to do with the identity of the host. As the public key is the
+only thing that truly matters, faking an IP, a port or any other
+property of the underlying transport protocol is irrelevant. In fact,
+GNUnet peers can use multiple IPs (IPv4 and IPv6) on multiple ports — or
+even not use the IP protocol at all (by running directly on layer 2).
+
+Peer identities are used to identify peers in the network and are unique
+for each peer. The identity for a peer is simply its public key, which
+is generated along with a private key when the peer is started for the
+first time. While the identity is binary data, it is often expressed as
+an ASCII string. For example, the following is a peer identity as you
+might see it in various places:
+
+::
+
+ UAT1S6PMPITLBKSJ2DGV341JI6KF7B66AC4JVCN9811NNEGQLUN0
+
+You can find your peer identity by running ``gnunet-core``.
+
+Almost all peer-to-peer communications in GNUnet are between mutually
+authenticated peers.
+GNUnet uses a special type of message to communicate a binding between
+public (ECC) keys to their current network address. These messages are
+commonly called **HELLOs** or peer advertisements. They contain the public
+key of the peer and its current network addresses for various transport
+services. A transport service is a special kind of shared library that
+provides (possibly unreliable, out-of-order) message delivery between
+peers. For the UDP and TCP transport services, a network address is an
+IP and a port. GNUnet can also use other transports (HTTP, HTTPS, WLAN,
+etc.) which use various other forms of addresses. Note that any node can
+have many different active transport services at the same time, and each
+of these can have a different addresses. Binding messages expire after
+at most a week (the timeout can be shorter if the user configures the
+node appropriately). This expiration ensures that the network will
+eventually get rid of outdated advertisements.
+
+For more information, refer to the following paper:
+
+Ronaldo A. Ferreira, Christian Grothoff, and Paul Ruth. A Transport
+Layer Abstraction for Peer-to-Peer Networks Proceedings of the 3rd
+International Symposium on Cluster Computing and the Grid (GRID 2003),
+2003. (https://git.gnunet.org/bibliography.git/plain/docs/transport.pdf)
+
+
Security goals and threat model
-------------------------
@@ -226,17 +276,24 @@ and see `Deniability <about.md#deniability>`__.
GNUnet attemtps to satisfy the following security goals in the face of those adversaries:
- 1. Censorship resistance
- 2. Confidential communication
- 3. Anonymity (where possible)
+1. Censorship resistance
+2. Confidential communication
+3. Anonymity (where possible)
From the lowest layer to the applications layer, the securty goals and associated subsystems are:
- 1. Base layer (Communicators/TRANSPORT): This layer optionally provides steganographic and ad-hoc security guarantees against external adversaries that largely depend on the communicator(s) used. For example, use of the HTTP3/QUIC communicator will use TLS and try to validate a certificate signed by the peer we want to connect to. Other communicators may not provide the same properties.
- 2. Peer connectivity and routing layer (CORE, R5N): This layer provides a secure channel between two (physically) connected peers. Peers are mutually authenticated and a secure cryptographic channel is established, but there is no particular trust required between the communication partners. It does not assume any security guarantees from the previous layer. It provides confidential communication in the face of an external adversary. The R5N uses this layer to establish an overlay network (DHT).
- 3. Peer connectivity layer (CADET): This layer provides an end-to-end secure secure cryptographic channel between two peers. It is assumed that this channel is established between to peers that share a strong trust relationship. It uses advanced cryptographic mechanisms to provide Perfect Forward Secrecy and Post-Compromise Security as well as the option to support out-of-order messages and participation repudiation (deniability).
- 4. Application layer: Each :ref:`subsystem <subsystems>` of GNUnet incorporates its own security mechanism taking the existing baseline of the GNUnet network as well as the adversary model into account. See the respective section in the User handbook.
+1. Base layer (Communicators/TRANSPORT): This layer optionally provides steganographic and ad-hoc security guarantees against external adversaries that largely depend on the communicator(s) used. For example, use of the HTTP3/QUIC communicator will use TLS and try to validate a certificate signed by the peer we want to connect to. Other communicators may not provide the same properties.
+ - QUIC Communicator: TLS (EdDSA/X25519)
+ - TCP Communicator: Diffie-Hellman KX (Ed25519-to-X25519-DH)
+2. Peer connectivity and routing layer (CORE, R5N): This layer provides a secure channel between two (physically) connected peers. Peers are mutually authenticated and a secure cryptographic channel is established, but there is no particular trust required between the communication partners. It does not assume any security guarantees from the previous layer. It provides confidential communication in the face of an external adversary. The R5N uses this layer to establish an overlay network (DHT).
+ - CORE: DTLS-style KEMTLS called CAKE with EdDSA and X25519. Specification: `LSD 0012 <https://lsd.gnunet.org/lsd0012/>`_
+ - R5N: EdDSA signatures: `LSD 0004 <https://lsd.gnunet.org/lsd0004/>`_
+3. Peer connectivity layer (CADET): This layer provides an end-to-end secure secure cryptographic channel between two peers. It is assumed that this channel is established between to peers that share a strong trust relationship. It uses advanced cryptographic mechanisms to provide Perfect Forward Secrecy and Post-Compromise Security as well as the option to support out-of-order messages and participation repudiation (deniability).
+ - CADET: Axolotl 3DH with EdDSA Peer Identities.
+4. Application layer: Each :ref:`subsystem <subsystems>` of GNUnet incorporates its own security mechanism taking the existing baseline of the GNUnet network as well as the adversary model into account. See the respective section in the User handbook.
+ - GNS: EDDSA+AES-CTR (PKEY zones) or EdDSA+XSalsa20-Poly1305 (EDKEY zones) with key blinding. Specification: `LSD 0001 <https://lsd.gnunet.org/lsd0012/>`_
+
Cryptography
------------
@@ -252,65 +309,6 @@ The primary asymmetric primitives in use are EdDSA and X25519.
Currently, no clear path to post-quantum primitives has been laid out.
This is mostly due to open research questions in the areas of key blinding and blind signatures.
-Peer Identities
-~~~~~~~~~~~~~~~
-
-In GNUnet, the identity of a host is its public key called **Peer Identity**.
-For that reason, man-in-the-middle attacks will not break the authentication or
-accounting goals. Essentially, for GNUnet, the IP of the host has
-nothing to do with the identity of the host. As the public key is the
-only thing that truly matters, faking an IP, a port or any other
-property of the underlying transport protocol is irrelevant. In fact,
-GNUnet peers can use multiple IPs (IPv4 and IPv6) on multiple ports — or
-even not use the IP protocol at all (by running directly on layer 2).
-
-Peer identities are used to identify peers in the network and are unique
-for each peer. The identity for a peer is simply its public key, which
-is generated along with a private key when the peer is started for the
-first time. While the identity is binary data, it is often expressed as
-an ASCII string. For example, the following is a peer identity as you
-might see it in various places:
-
-::
-
- UAT1S6PMPITLBKSJ2DGV341JI6KF7B66AC4JVCN9811NNEGQLUN0
-
-You can find your peer identity by running ``gnunet-core``.
-
-Almost all peer-to-peer communications in GNUnet are between mutually
-authenticated peers. The authentication works by using ECDHE, that is a
-DH (Diffie—Hellman) key exchange using ephemeral elliptic curve
-cryptography. The ephemeral ECC (Elliptic Curve Cryptography) keys are
-signed using **EdDSA**. The shared secret from ECDHE is used to create a
-pair of session keys (using HKDF) which are then used to encrypt the
-communication between the two peers using both **256-bit AES**
-and **256-bit Twofish** (with independently derived
-secret keys). As only the two participating hosts know the shared
-secret, this authenticates each packet without requiring signatures each
-time. GNUnet mostly uses the **SHA-512** hash algorithm.
-
-GNUnet uses a special type of message to communicate a binding between
-public (ECC) keys to their current network address. These messages are
-commonly called **HELLOs** or peer advertisements. They contain the public
-key of the peer and its current network addresses for various transport
-services. A transport service is a special kind of shared library that
-provides (possibly unreliable, out-of-order) message delivery between
-peers. For the UDP and TCP transport services, a network address is an
-IP and a port. GNUnet can also use other transports (HTTP, HTTPS, WLAN,
-etc.) which use various other forms of addresses. Note that any node can
-have many different active transport services at the same time, and each
-of these can have a different addresses. Binding messages expire after
-at most a week (the timeout can be shorter if the user configures the
-node appropriately). This expiration ensures that the network will
-eventually get rid of outdated advertisements.
-
-For more information, refer to the following paper:
-
-Ronaldo A. Ferreira, Christian Grothoff, and Paul Ruth. A Transport
-Layer Abstraction for Peer-to-Peer Networks Proceedings of the 3rd
-International Symposium on Cluster Computing and the Grid (GRID 2003),
-2003. (https://git.gnunet.org/bibliography.git/plain/docs/transport.pdf)
-
Egos
~~~~
