commit 2eabac0ae82fe5d92b67c8627235ca68e131a407
parent 900656486fbf2f9bab861aba19ca220f77313abb
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Sat, 24 Feb 2024 11:38:38 +0100
move crypto and move confidentiality
Diffstat:
| M | about.rst | | | 225 | +++++++++++++++++++++++++++++++++++++++---------------------------------------- |
1 file changed, 112 insertions(+), 113 deletions(-)
diff --git a/about.rst b/about.rst
@@ -165,6 +165,118 @@ of them are also described in our research papers. First, some of the
concepts used in the GNUnet framework are detailed. The second part
describes concepts specific to anonymous file-sharing.
+Cryptography
+------------
+
+Adversaries (malicious, bad actors) outside of GNUnet are not supposed
+to know what kind of actions a peer is involved in. Only the specific
+neighbor of a peer that is the corresponding sender or recipient of a
+message may know its contents, and even then application protocols may
+place further restrictions on that knowledge. In order to ensure
+confidentiality, GNUnet uses link encryption, that is each message
+exchanged between two peers is encrypted using a pair of keys only known
+to these two peers. Encrypting traffic like this makes any kind of
+traffic analysis much harder. Naturally, for some applications, it may
+still be desirable if even neighbors cannot determine the concrete
+contents of a message. In GNUnet, this problem is addressed by the
+specific application-level protocols. See for example the following
+sections: `Anonymity <about.md#anonymity>`__, see `How file-sharing
+achieves Anonymity <about.md#how-file-sharing-achieves-anonymity>`__,
+and see `Deniability <about.md#deniability>`__.
+
+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
+~~~~
+
+**Egos** are your “identities” in GNUnet. Any user can assume multiple
+identities, for example to separate their activities online. Egos can
+correspond to “pseudonyms” or “real-world identities”. Technically an
+ego is first of all a key pair of a public- and private-key.
+The current primary use for Egos are in the GNU Name System as zone keys.
+
+Zones in the GNU Name System
+""""""""""""""""""""""""""""
+
+Egos are used as **GNS zones**.
+
+GNS zones are similar to those of DNS zones, but instead of a hierarchy
+of authorities to governing their use, GNS zones are controlled by a
+private key. When you create a record in a DNS zone, that information is
+stored in your nameserver. Anyone trying to resolve your domain then
+gets pointed (hopefully) by the centralised authority to your
+nameserver. Whereas GNS, being fully decentralized by design, stores
+that information in DHT. The validity of the records is assured
+cryptographically, by signing them with the private key of the
+respective zone.
+
+Anyone trying to resolve records in a zone of your domain can then
+verify the signature of the records they get from the DHT and be assured
+that they are indeed from the respective zone. To make this work, there
+is a 1:1 correspondence between zones and their public-private key
+pairs. So when we talk about the owner of a GNS zone, that’s really the
+owner of the private key. And a user accessing a zone needs to somehow
+specify the corresponding public key first.
+
+For more information, refer to RFC 9498.
Accounting to Encourage Resource Sharing
----------------------------------------
@@ -201,24 +313,6 @@ An Excess-Based Economic Model for Resource Allocation in Peer-to-Peer
Networks. Wirtschaftsinformatik, June 2003.
(https://git.gnunet.org/bibliography.git/plain/docs/ebe.pdf)
-Confidentiality
----------------
-
-Adversaries (malicious, bad actors) outside of GNUnet are not supposed
-to know what kind of actions a peer is involved in. Only the specific
-neighbor of a peer that is the corresponding sender or recipient of a
-message may know its contents, and even then application protocols may
-place further restrictions on that knowledge. In order to ensure
-confidentiality, GNUnet uses link encryption, that is each message
-exchanged between two peers is encrypted using a pair of keys only known
-to these two peers. Encrypting traffic like this makes any kind of
-traffic analysis much harder. Naturally, for some applications, it may
-still be desirable if even neighbors cannot determine the concrete
-contents of a message. In GNUnet, this problem is addressed by the
-specific application-level protocols. See for example the following
-sections: `Anonymity <about.md#anonymity>`__, see `How file-sharing
-achieves Anonymity <about.md#how-file-sharing-achieves-anonymity>`__,
-and see `Deniability <about.md#deniability>`__.
Anonymity
---------
@@ -337,99 +431,4 @@ Grothoff, Tzvetan Horozov, and Jussi T. Lindgren. An Encoding for
Censorship-Resistant Sharing. 2009.
(https://git.gnunet.org/bibliography.git/plain/docs/ecrs.pdf)
-Cryptography
-------------
-
-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
-~~~~
-
-**Egos** are your “identities” in GNUnet. Any user can assume multiple
-identities, for example to separate their activities online. Egos can
-correspond to “pseudonyms” or “real-world identities”. Technically an
-ego is first of all a key pair of a public- and private-key.
-The current primary use for Egos are in the GNU Name System as zone keys.
-
-Zones in the GNU Name System
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Egos are used as **GNS zones**.
-
-GNS zones are similar to those of DNS zones, but instead of a hierarchy
-of authorities to governing their use, GNS zones are controlled by a
-private key. When you create a record in a DNS zone, that information is
-stored in your nameserver. Anyone trying to resolve your domain then
-gets pointed (hopefully) by the centralised authority to your
-nameserver. Whereas GNS, being fully decentralized by design, stores
-that information in DHT. The validity of the records is assured
-cryptographically, by signing them with the private key of the
-respective zone.
-
-Anyone trying to resolve records in a zone of your domain can then
-verify the signature of the records they get from the DHT and be assured
-that they are indeed from the respective zone. To make this work, there
-is a 1:1 correspondence between zones and their public-private key
-pairs. So when we talk about the owner of a GNS zone, that’s really the
-owner of the private key. And a user accessing a zone needs to somehow
-specify the corresponding public key first.
-
-For more information, refer to RFC 9498.
