about.rst (22158B)
1 ************ 2 About GNUnet 3 ************ 4 5 GNUnet in its current version is the result of over 20 years of work 6 from many contributors. So far, most contributions were made by 7 volunteers or people paid to do fundamental research. At this stage, 8 GNUnet remains an experimental system where significant parts of the 9 software lack a reasonable degree of professionalism in its 10 implementation. Furthermore, we are aware of a significant number of 11 existing bugs and critical design flaws, as some unfortunate early 12 design decisions remain to be rectified. There are still known open 13 problems; GNUnet remains an active research project. 14 15 The project was started in 2001 when some initial ideas for improving 16 Freenet’s file-sharing turned out to be too radical to be easily 17 realized within the scope of the existing Freenet project. We lost our 18 first contributor on 11.9.2001 as the contributor realized that privacy 19 may help terrorists. The rest of the team concluded that it was now even 20 more important to fight for civil liberties. The first release was 21 called “GNet” – already with the name GNUnet in mind, but without the 22 blessing of GNU we did not dare to call it GNUnet immediately. A few 23 months after the first release we contacted the GNU project, happily 24 agreed to their governance model and became an official GNU package. 25 26 Within the first year, we created GNU libextractor, a helper library for 27 meta data extraction which has been used by a few other projects as 28 well. 2003 saw the emergence of pluggable transports, the ability for 29 GNUnet to use different mechanisms for communication, starting with TCP, 30 UDP and SMTP (support for the latter was later dropped due to a lack of 31 maintenance). In 2005, the project first started to evolve beyond the 32 original file-sharing application with a first simple P2P chat. In 2007, 33 we created GNU libmicrohttpd to support a pluggable transport based on 34 HTTP. In 2009, the architecture was radically modularized into the 35 multi-process system that exists today. Coincidentally, the first 36 version of the ARM service (ARM: Automatic Restart Manager) was 37 implemented a day before systemd was announced. From 2009 to 2014 work 38 progressed rapidly thanks to a significant research grant from the 39 Deutsche Forschungsgesellschaft. This resulted in particular in the 40 creation of the R5N DHT, CADET, ATS and the GNU Name System. In 2010, 41 GNUnet was selected as the basis for the secushare online social 42 network, resulting in a significant growth of the core team. In 2013, we 43 launched GNU Taler to address the challenge of convenient and 44 privacy-preserving online payments. In 2015, the pretty Easy privacy 45 (pEp) project announced that they will use GNUnet as the technology for 46 their meta-data protection layer, ultimately resulting in GNUnet e.V. 47 entering into a formal long-term collaboration with the pEp Foundation. 48 In 2016, Taler Systems SA, a first startup using GNUnet technology, was 49 founded with support from the community. 50 51 GNUnet is not merely a technical project, but also a political mission: 52 like the GNU project as a whole, we are writing software to achieve 53 political goals with a focus on the human right of informational 54 self-determination. Putting users in control of their computing has been 55 the core driver of the GNU project. With GNUnet we are focusing on 56 informational self-determination for collaborative computing and 57 communication over networks. 58 59 The Internet is shaped as much by code and protocols as it is by its 60 associated political processes (IETF, ICANN, IEEE, etc.). Similarly its 61 flaws are not limited to the protocol design. Thus, technical excellence 62 by itself will not suffice to create a better network. We also need to 63 build a community that is wise, humble and has a sense of humor to 64 achieve our goal to create a technical foundation for a society we would 65 like to live in. 66 67 Project governance 68 ================== 69 70 GNUnet, like the GNU project and many other free software projects, 71 follows the governance model of a benevolent dictator. This means that 72 ultimately, the GNU project appoints the GNU maintainer and can overrule 73 decisions made by the GNUnet maintainer. Similarly, the GNUnet 74 maintainer can overrule any decisions made by individual developers. 75 Still, in practice neither has happened in the last 20 years for GNUnet, 76 and we hope to keep it that way. 77 78 The current maintainers of GNUnet are: 79 80 - `Christian Grothoff <https://grothoff.org/christian/>`__ 81 - `Martin Schanzenbach <https://schanzen.eu/>`__ 82 83 The GNUnet project is supported by GNUnet e.V., a German association 84 where any developer can become a member. GNUnet e.V. serves as a legal 85 entity to hold the copyrights to GNUnet. GNUnet e.V. may also choose to 86 pay for project resources, and can collect donations as well as choose 87 to adjust the license of the software (with the constraint that it has 88 to remain free software). In 2018 we switched from GPL3 to AGPL3, in 89 practice these changes do not happen very often. 90 91 Philosophy 92 ========== 93 94 The primary goal of the GNUnet project is to provide a reliable, open, 95 non-discriminating and censorship-resistant system for information 96 exchange. We value free speech above state interests and intellectual 97 monopoly. GNUnet’s long-term goal is to serve as a development platform 98 for the next generation of Internet protocols. 99 100 Participants are encouraged to contribute at least as much resources 101 (storage, bandwidth) to the network as they consume, so that their 102 participation does not have a negative impact on other users. 103 104 Design Principles 105 ----------------- 106 107 These are the GNUnet design principles, in order of importance: 108 109 - GNUnet must be implemented as Free Software — This means that you 110 have the four essential freedoms: to run the program, to study and 111 change the program in source code form, to redistribute exact copies, 112 and to distribute modified versions. 113 (https://www.gnu.org/philosophy/free-sw.html). 114 - GNUnet must minimize the amount of personally identifiable 115 information exposed. 116 - GNUnet must be fully distributed and resilient to external attacks 117 and rogue participants. 118 - GNUnet must be self-organizing and not depend on administrators or 119 centralized infrastructure. 120 - GNUnet must inform the user which other participants have to be 121 trusted when establishing private communications. 122 - GNUnet must be open and permit new peers to join. 123 - GNUnet must support a diverse range of applications and devices. 124 - GNUnet must use compartmentalization to protect sensitive 125 information. 126 - The GNUnet architecture must be resource efficient. 127 - GNUnet must provide incentives for peers to contribute more resources 128 than they consume. 129 130 Privacy and Anonymity 131 --------------------- 132 133 The GNUnet protocols minimize the leakage of personally identifiable 134 information of participants and do not allow adversaries to control, 135 track, monitor or censor users activities. The GNUnet protocols also 136 make it as hard as possible to disrupt operations by participating in 137 the network with malicious intent. 138 139 Analyzing participant’s activities becomes more difficult as the number 140 of peers and applications that generate traffic on the network grows, 141 even if the additional traffic generated is not related to anonymous 142 communication. This is one of the reasons why GNUnet is developed as a 143 peer-to-peer framework where many applications share the lower layers of 144 an increasingly complex protocol stack. The GNUnet architecture 145 encourages many different forms of peer-to-peer applications. 146 147 Practicality 148 ------------ 149 150 Wherever possible GNUnet allows the peer to adjust its operations and 151 functionalities to specific use cases. A GNUnet peer running on a mobile 152 device with limited battery for example might choose not to relay 153 traffic for other participants. 154 155 For certain applications like file-sharing GNUnet allows participants to 156 trade degrees of anonymity in exchange for increased efficiency. 157 However, it is not possible for any user’s efficiency requirements to 158 compromise the anonymity of any other user. 159 160 Key Concepts 161 ============ 162 163 In this section, the fundamental concepts of GNUnet are explained. Most 164 of them are also described in our research papers. First, some of the 165 concepts used in the GNUnet framework are detailed. The second part 166 describes concepts specific to anonymous file-sharing. 167 168 Cryptography 169 ------------ 170 171 Adversaries (malicious, bad actors) outside of GNUnet are not supposed 172 to know what kind of actions a peer is involved in. Only the specific 173 neighbor of a peer that is the corresponding sender or recipient of a 174 message may know its contents, and even then application protocols may 175 place further restrictions on that knowledge. In order to ensure 176 confidentiality, GNUnet uses link encryption, that is each message 177 exchanged between two peers is encrypted using a pair of keys only known 178 to these two peers. Encrypting traffic like this makes any kind of 179 traffic analysis much harder. Naturally, for some applications, it may 180 still be desirable if even neighbors cannot determine the concrete 181 contents of a message. In GNUnet, this problem is addressed by the 182 specific application-level protocols. See for example the following 183 sections: `Anonymity <about.md#anonymity>`__, see `How file-sharing 184 achieves Anonymity <about.md#how-file-sharing-achieves-anonymity>`__, 185 and see `Deniability <about.md#deniability>`__. 186 187 Peer Identities 188 ~~~~~~~~~~~~~~~ 189 190 In GNUnet, the identity of a host is its public key called **Peer Identity**. 191 For that reason, man-in-the-middle attacks will not break the authentication or 192 accounting goals. Essentially, for GNUnet, the IP of the host has 193 nothing to do with the identity of the host. As the public key is the 194 only thing that truly matters, faking an IP, a port or any other 195 property of the underlying transport protocol is irrelevant. In fact, 196 GNUnet peers can use multiple IPs (IPv4 and IPv6) on multiple ports — or 197 even not use the IP protocol at all (by running directly on layer 2). 198 199 Peer identities are used to identify peers in the network and are unique 200 for each peer. The identity for a peer is simply its public key, which 201 is generated along with a private key when the peer is started for the 202 first time. While the identity is binary data, it is often expressed as 203 an ASCII string. For example, the following is a peer identity as you 204 might see it in various places: 205 206 :: 207 208 UAT1S6PMPITLBKSJ2DGV341JI6KF7B66AC4JVCN9811NNEGQLUN0 209 210 You can find your peer identity by running ``gnunet-core``. 211 212 Almost all peer-to-peer communications in GNUnet are between mutually 213 authenticated peers. The authentication works by using ECDHE, that is a 214 DH (Diffie—Hellman) key exchange using ephemeral elliptic curve 215 cryptography. The ephemeral ECC (Elliptic Curve Cryptography) keys are 216 signed using **EdDSA**. The shared secret from ECDHE is used to create a 217 pair of session keys (using HKDF) which are then used to encrypt the 218 communication between the two peers using both **256-bit AES** 219 and **256-bit Twofish** (with independently derived 220 secret keys). As only the two participating hosts know the shared 221 secret, this authenticates each packet without requiring signatures each 222 time. GNUnet mostly uses the **SHA-512** hash algorithm. 223 224 GNUnet uses a special type of message to communicate a binding between 225 public (ECC) keys to their current network address. These messages are 226 commonly called **HELLOs** or peer advertisements. They contain the public 227 key of the peer and its current network addresses for various transport 228 services. A transport service is a special kind of shared library that 229 provides (possibly unreliable, out-of-order) message delivery between 230 peers. For the UDP and TCP transport services, a network address is an 231 IP and a port. GNUnet can also use other transports (HTTP, HTTPS, WLAN, 232 etc.) which use various other forms of addresses. Note that any node can 233 have many different active transport services at the same time, and each 234 of these can have a different addresses. Binding messages expire after 235 at most a week (the timeout can be shorter if the user configures the 236 node appropriately). This expiration ensures that the network will 237 eventually get rid of outdated advertisements. 238 239 For more information, refer to the following paper: 240 241 Ronaldo A. Ferreira, Christian Grothoff, and Paul Ruth. A Transport 242 Layer Abstraction for Peer-to-Peer Networks Proceedings of the 3rd 243 International Symposium on Cluster Computing and the Grid (GRID 2003), 244 2003. (https://git.gnunet.org/bibliography.git/plain/docs/transport.pdf) 245 246 247 Egos 248 ~~~~ 249 250 **Egos** are your “identities” in GNUnet. Any user can assume multiple 251 identities, for example to separate their activities online. Egos can 252 correspond to “pseudonyms” or “real-world identities”. Technically an 253 ego is first of all a key pair of a public- and private-key. 254 The current primary use for Egos are in the GNU Name System as zone keys. 255 256 Zones in the GNU Name System 257 """""""""""""""""""""""""""" 258 259 Egos are used as **GNS zones**. 260 261 GNS zones are similar to those of DNS zones, but instead of a hierarchy 262 of authorities to governing their use, GNS zones are controlled by a 263 private key. When you create a record in a DNS zone, that information is 264 stored in your nameserver. Anyone trying to resolve your domain then 265 gets pointed (hopefully) by the centralised authority to your 266 nameserver. Whereas GNS, being fully decentralized by design, stores 267 that information in DHT. The validity of the records is assured 268 cryptographically, by signing them with the private key of the 269 respective zone. 270 271 Anyone trying to resolve records in a zone of your domain can then 272 verify the signature of the records they get from the DHT and be assured 273 that they are indeed from the respective zone. To make this work, there 274 is a 1:1 correspondence between zones and their public-private key 275 pairs. So when we talk about the owner of a GNS zone, that’s really the 276 owner of the private key. And a user accessing a zone needs to somehow 277 specify the corresponding public key first. 278 279 For more information, refer to RFC 9498. 280 281 282 283 Anonymity 284 --------- 285 286 Providing anonymity for users is the central goal for the anonymous 287 file-sharing application. Many other design decisions follow in the 288 footsteps of this requirement. Anonymity is never absolute. While there 289 are various scientific metrics (Claudia Díaz, Stefaan Seys, Joris 290 Claessens, and Bart Preneel. Towards measuring anonymity. 2002. 291 (https://git.gnunet.org/bibliography.git/plain/docs/article-89.pdf)) 292 that can help quantify the level of anonymity that a given mechanism 293 provides, there is no such thing as “complete anonymity”. 294 295 GNUnet’s file-sharing implementation allows users to select for each 296 operation (publish, search, download) the desired level of anonymity. 297 The metric used is based on the amount of cover traffic needed to hide 298 the request. 299 300 While there is no clear way to relate the amount of available cover 301 traffic to traditional scientific metrics such as the anonymity set or 302 information leakage, it is probably the best metric available to a peer 303 with a purely local view of the world, in that it does not rely on 304 unreliable external information or a particular adversary model. 305 306 The default anonymity level is 1, which uses anonymous routing but 307 imposes no minimal requirements on cover traffic. It is possible to 308 forego anonymity when this is not required. The anonymity level of 0 309 allows GNUnet to use more efficient, non-anonymous routing. 310 311 How file-sharing achieves Anonymity 312 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 313 314 Contrary to other designs, we do not believe that users achieve strong 315 anonymity just because their requests are obfuscated by a couple of 316 indirections. This is not sufficient if the adversary uses traffic 317 analysis. The threat model used for anonymous file sharing in GNUnet 318 assumes that the adversary is quite powerful. In particular, we assume 319 that the adversary can see all the traffic on the Internet. And while we 320 assume that the adversary can not break our encryption, we assume that 321 the adversary has many participating nodes in the network and that it 322 can thus see many of the node-to-node interactions since it controls 323 some of the nodes. 324 325 The system tries to achieve anonymity based on the idea that users can 326 be anonymous if they can hide their actions in the traffic created by 327 other users. Hiding actions in the traffic of other users requires 328 participating in the traffic, bringing back the traditional technique of 329 using indirection and source rewriting. Source rewriting is required to 330 gain anonymity since otherwise an adversary could tell if a message 331 originated from a host by looking at the source address. If all packets 332 look like they originate from one node, the adversary can not tell which 333 ones originate from that node and which ones were routed. Note that in 334 this mindset, any node can decide to break the source-rewriting paradigm 335 without violating the protocol, as this only reduces the amount of 336 traffic that a node can hide its own traffic in. 337 338 If we want to hide our actions in the traffic of other nodes, we must 339 make our traffic indistinguishable from the traffic that we route for 340 others. As our queries must have us as the receiver of the reply 341 (otherwise they would be useless), we must put ourselves as the receiver 342 of replies that actually go to other hosts; in other words, we must 343 indirect replies. Unlike other systems, in anonymous file-sharing as 344 implemented on top of GNUnet we do not have to indirect the replies if 345 we don’t think we need more traffic to hide our own actions. 346 347 This increases the efficiency of the network as we can indirect less 348 under higher load. Refer to the following paper for more: Krista Bennett 349 and Christian Grothoff. GAP — practical anonymous networking. In 350 Proceedings of Designing Privacy Enhancing Technologies, 2003. 351 (https://git.gnunet.org/bibliography.git/plain/docs/aff.pdf) 352 353 How messaging provided Anonymity 354 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 355 356 While the file-sharing tries to achieve anonymity through hiding actions 357 in other traffic, the messaging service provides a weaker form of 358 protection against identification. 359 360 The messaging service allows the use of an anonymous ego for the signing 361 and verification process of messages instead of a unique ego. This 362 anonymous ego is a publicly known key pair which is shared between all 363 peers in GNUnet. 364 365 Using this ego only ensures that individual messages alone can’t 366 identify its sender inside of a messenger room. It should be clarified 367 that the route of the traffic for each message can still be tracked to 368 identify the senders peer inside of a messenger room if the threat agent 369 controls certain peers hosting the room. 370 371 Also opening a room in the messenger service will potentially match your 372 peer identity with the internal member identity from the messenger 373 service. So despite using the anonymous ego you can reveal your peer 374 identity. This means to decrease the chance of being identified, it is 375 recommended to enter rooms but you should not open them for others. 376 377 Deniability 378 ----------- 379 380 Even if the user that downloads data and the server that provides data 381 are anonymous, the intermediaries may still be targets. In particular, 382 if the intermediaries can find out which queries or which content they 383 are processing, a strong adversary could try to force them to censor 384 certain materials. 385 386 With the file-encoding used by GNUnet’s anonymous file-sharing, this 387 problem does not arise. The reason is that queries and replies are 388 transmitted in an encrypted format such that intermediaries cannot tell 389 what the query is for or what the content is about. Mind that this is 390 not the same encryption as the link-encryption between the nodes. GNUnet 391 has encryption on the network layer (link encryption, confidentiality, 392 authentication) and again on the application layer (provided by 393 gnunet-publish, gnunet-download, gnunet-search and gnunet-fs-gtk). 394 395 Refer to the following paper for more: Christian Grothoff, Krista 396 Grothoff, Tzvetan Horozov, and Jussi T. Lindgren. An Encoding for 397 Censorship-Resistant Sharing. 2009. 398 (https://git.gnunet.org/bibliography.git/plain/docs/ecrs.pdf) 399 400 Accounting to Encourage Resource Sharing 401 ---------------------------------------- 402 403 Most distributed P2P networks suffer from a lack of defenses or 404 precautions against attacks in the form of freeloading. While the 405 intentions of an attacker and a freeloader are different, their effect 406 on the network is the same; they both render it useless. Most simple 407 attacks on networks such as Gnutella involve flooding the network with 408 traffic, particularly with queries that are, in the worst case, 409 multiplied by the network. 410 411 In order to ensure that freeloaders or attackers have a minimal impact 412 on the network, GNUnet’s file-sharing implementation (FS) tries to 413 distinguish good (contributing) nodes from malicious (freeloading) 414 nodes. In GNUnet, every file-sharing node keeps track of the behavior of 415 every other node it has been in contact with. Many requests (depending 416 on the application) are transmitted with a priority (or importance) 417 level. That priority is used to establish how important the sender 418 believes this request is. If a peer responds to an important request, 419 the recipient will increase its trust in the responder: the responder 420 contributed resources. If a peer is too busy to answer all requests, it 421 needs to prioritize. For that, peers do not take the priorities of the 422 requests received at face value. First, they check how much they trust 423 the sender, and depending on that amount of trust they assign the 424 request a (possibly lower) effective priority. Then, they drop the 425 requests with the lowest effective priority to satisfy their resource 426 constraints. This way, GNUnet’s economic model ensures that nodes that 427 are not currently considered to have a surplus in contributions will not 428 be served if the network load is high. 429 430 For more information, refer to the following paper: Christian Grothoff. 431 An Excess-Based Economic Model for Resource Allocation in Peer-to-Peer 432 Networks. Wirtschaftsinformatik, June 2003. 433 (https://git.gnunet.org/bibliography.git/plain/docs/ebe.pdf) 434