diff options
Diffstat (limited to 'doc/documentation/chapters/philosophy.texi')
-rw-r--r-- | doc/documentation/chapters/philosophy.texi | 446 |
1 files changed, 42 insertions, 404 deletions
diff --git a/doc/documentation/chapters/philosophy.texi b/doc/documentation/chapters/philosophy.texi index 72c3476a3..6d80d77ae 100644 --- a/doc/documentation/chapters/philosophy.texi +++ b/doc/documentation/chapters/philosophy.texi | |||
@@ -5,36 +5,28 @@ | |||
5 | @c NOTE: We should probably re-use some of the images lynX created | 5 | @c NOTE: We should probably re-use some of the images lynX created |
6 | @c for secushare, showing some of the relations and functionalities | 6 | @c for secushare, showing some of the relations and functionalities |
7 | @c of GNUnet. | 7 | @c of GNUnet. |
8 | The foremost goal of the GNUnet project is to become a widely used, | 8 | The primary goal of the GNUnet project is to provide a reliable, open, |
9 | reliable, open, non-discriminating, egalitarian, unconstrained and | 9 | non-discriminating and censorship-resistant system for information |
10 | censorship-resistant system of free information exchange. | 10 | exchange. We value free speech above state interests and intellectual |
11 | We value free speech above state secrets, law-enforcement or | 11 | monopoly. GNUnet's long-term goal is to serve as a development |
12 | intellectual monopoly. | 12 | platform for the next generation of Internet protocols. |
13 | GNUnet is supposed to be an anarchistic network, where the only | 13 | |
14 | limitation for participants (devices or people making use of the | 14 | GNUnet is an anarchistic network. Participants are encouraged to |
15 | network, in the following sometimes called peers) is | 15 | contribute at least as much resources (storage, bandwidth) to the network |
16 | that they must contribute enough back to the network such that | 16 | as they consume, so that their participation does not have a negative |
17 | their resource consumption does not have a significant impact | 17 | impact on other users. |
18 | on other users. | ||
19 | GNUnet should be more than just another file-sharing network. | ||
20 | The plan is to offer many other services and in particular | ||
21 | to serve as a development platform for the next generation of | ||
22 | Internet Protocols. | ||
23 | 18 | ||
24 | @menu | 19 | @menu |
25 | * Design Goals:: | 20 | * Design Principles:: |
26 | * Security and Privacy:: | 21 | * Privacy and Anonymity:: |
27 | * Versatility:: | ||
28 | * Practicality:: | 22 | * Practicality:: |
29 | * Key Concepts:: | ||
30 | @end menu | 23 | @end menu |
31 | 24 | ||
32 | @cindex Design Goals | 25 | @cindex Design Principles |
33 | @cindex Design Goals | 26 | @node Design Principles |
34 | @node Design Goals | 27 | @section Design Principles |
35 | @section Design Goals | ||
36 | 28 | ||
37 | These are the core GNUnet design goals, in order of relative importance: | 29 | These are the GNUnet design principles, in order of importance: |
38 | 30 | ||
39 | @itemize | 31 | @itemize |
40 | @item GNUnet must be implemented as | 32 | @item GNUnet must be implemented as |
@@ -44,399 +36,45 @@ These are the core GNUnet design goals, in order of relative importance: | |||
44 | the program, to study and change the program in source code form, | 36 | the program, to study and change the program in source code form, |
45 | to redistribute exact copies, and to distribute modified versions. | 37 | to redistribute exact copies, and to distribute modified versions. |
46 | Refer to @uref{https://www.gnu.org/philosophy/free-sw.html, https://www.gnu.org/philosophy/free-sw.html}} | 38 | Refer to @uref{https://www.gnu.org/philosophy/free-sw.html, https://www.gnu.org/philosophy/free-sw.html}} |
47 | @item GNUnet must only disclose the minimal amount of information | 39 | @item GNUnet must minimize the amount of personally identifiable information exposed. |
48 | necessary. | ||
49 | @c TODO: Explain 'fully' in the terminology section. | 40 | @c TODO: Explain 'fully' in the terminology section. |
50 | @item GNUnet must be fully distributed and survive | 41 | @item GNUnet must be fully distributed and resilient to external attacks and rogue participants. |
51 | @uref{https://en.wikipedia.org/wiki/Byzantine_fault_tolerance, Byzantine failures} | 42 | @item GNUnet must be self-organizing and not depend on administrators or centralized infrastructure. |
52 | @footnote{@uref{https://en.wikipedia.org/wiki/Byzantine_fault_tolerance, https://en.wikipedia.org/wiki/Byzantine_fault_tolerance}} | 43 | @item GNUnet must inform the user which other participants have to be trusted when establishing private communications. |
53 | at any position in the network. | ||
54 | @item GNUnet must make it explicit to the user which entities are | ||
55 | considered to be trustworthy when establishing secured communications. | ||
56 | @item GNUnet must use compartmentalization to protect sensitive | ||
57 | information. | ||
58 | @item GNUnet must be open and permit new peers to join. | 44 | @item GNUnet must be open and permit new peers to join. |
59 | @item GNUnet must be self-organizing and not depend on administrators. | ||
60 | @item GNUnet must support a diverse range of applications and devices. | 45 | @item GNUnet must support a diverse range of applications and devices. |
61 | @item The GNUnet architecture must be cost effective. | 46 | @item GNUnet must use compartmentalization to protect sensitive information. |
62 | @item GNUnet must provide incentives for peers to contribute more | 47 | @item The GNUnet architecture must be resource efficient. |
63 | resources than they consume. | 48 | @item GNUnet must provide incentives for peers to contribute more resources than they consume. |
64 | @end itemize | 49 | @end itemize |
65 | 50 | ||
66 | 51 | ||
67 | @cindex Security and Privacy | 52 | @cindex Privacy and Anonymity |
68 | @node Security and Privacy | 53 | @node Privacy and Anonymity |
69 | @section Security and Privacy | 54 | @section Privacy and Anonymity |
70 | |||
71 | GNUnet's primary design goals are to protect the privacy of its users and | ||
72 | to guard itself against attacks or abuse. | ||
73 | GNUnet does not have any mechanisms to control, track or censor users. | ||
74 | Instead, the GNUnet protocols aim to make it as hard as possible to | ||
75 | find out what is happening on the network or to disrupt operations. | ||
76 | 55 | ||
77 | @cindex Versatility | 56 | The GNUnet protocols minimize the leakage of personally identifiable information of participants and |
78 | @node Versatility | 57 | do not allow adversaries to control, track, monitor or censor users activities. The |
79 | @section Versatility | 58 | GNUnet protocols also make it as hard as possible to disrupt operations by participating in the network with malicious intent. |
80 | 59 | ||
81 | We call GNUnet a peer-to-peer framework because we want to support many | 60 | Analyzing participant's activities becomes more difficult as the number of peers and |
82 | different forms of peer-to-peer applications. GNUnet uses a plugin | 61 | applications that generate traffic on the network grows, even if the additional |
83 | architecture to make the system extensible and to encourage code reuse. | 62 | traffic generated is not related to anonymous communication. This is one of the reasons why GNUnet is developed as a peer-to-peer |
84 | While the first versions of the system only supported anonymous | ||
85 | file-sharing, other applications are being worked on and more will | ||
86 | hopefully follow in the future. | ||
87 | A powerful synergy regarding anonymity services is created by a large | ||
88 | community utilizing many diverse applications over the same software | ||
89 | infrastructure. The reason is that link encryption hides the specifics | ||
90 | of the traffic for non-participating observers. This way, anonymity can | ||
91 | get stronger with additional (GNUnet) traffic, even if the additional | ||
92 | traffic is not related to anonymous communication. Increasing anonymity | ||
93 | is the primary reason why GNUnet is developed to become a peer-to-peer | ||
94 | framework where many applications share the lower layers of an | 63 | framework where many applications share the lower layers of an |
95 | increasingly complex protocol stack. | 64 | increasingly complex protocol stack. The GNUnet architecture encourages many |
96 | If merging traffic to hinder traffic analysis was not important, | 65 | different forms of peer-to-peer applications. |
97 | we could have just developed a dozen stand-alone applications | ||
98 | and a few shared libraries. | ||
99 | 66 | ||
100 | @cindex Practicality | 67 | @cindex Practicality |
101 | @node Practicality | 68 | @node Practicality |
102 | @section Practicality | 69 | @section Practicality |
103 | 70 | ||
104 | GNUnet allows participants to trade various amounts of security in | 71 | Whereever possible GNUnet allows the peer to adjust its operations |
105 | exchange for increased efficiency. However, it is not possible for any | 72 | and functionalities to specific use cases. A GNUnet peer running on |
106 | user's security and efficiency requirements to compromise the security | 73 | a mobile device with limited battery for example might choose not to |
107 | and efficiency of any other user. | 74 | relay traffic for other participants. |
108 | |||
109 | For GNUnet, efficiency is not paramount. If there were a more secure and | ||
110 | still practical approach, we would choose to take the more secure | ||
111 | alternative. @command{telnet} is more efficient than @command{ssh}, yet | ||
112 | it is obsolete. | ||
113 | Hardware gets faster, and code can be optimized. Fixing security issues | ||
114 | as an afterthought is much harder. | ||
115 | |||
116 | While security is paramount, practicability is still a requirement. | ||
117 | The most secure system is always the one that nobody can use. | ||
118 | Similarly, any anonymous system that is extremely inefficient will only | ||
119 | find few users. | ||
120 | However, good anonymity requires a large and diverse user base. Since | ||
121 | individual security requirements may vary, the only good solution here is | ||
122 | to allow individuals to trade-off security and efficiency. | ||
123 | The primary challenge in allowing this is to ensure that the economic | ||
124 | incentives work properly. | ||
125 | In particular, this means that it must be impossible for a user to gain | ||
126 | security at the expense of other users. Many designs (e.g. anonymity via | ||
127 | broadcast) fail to give users an incentive to choose a less secure but | ||
128 | more efficient mode of operation. | ||
129 | GNUnet should avoid where ever possible to rely on protocols that will | ||
130 | only work if the participants are benevolent. | ||
131 | While some designs have had widespread success while relying on parties | ||
132 | to observe a protocol that may be sub-optimal for the individuals (e.g. | ||
133 | TCP Nagle), a protocol that ensures that individual goals never conflict | ||
134 | with the goals of the group is always preferable. | ||
135 | |||
136 | @cindex Key Concepts | ||
137 | @node Key Concepts | ||
138 | @section Key Concepts | ||
139 | |||
140 | In this section, the fundamental concepts of GNUnet are explained. | ||
141 | @c FIXME: Use @uref{https://docs.gnunet.org/bib/, research papers} | ||
142 | @c once we have the new bibliography + subdomain setup. | ||
143 | Most of them are also described in our research papers. | ||
144 | First, some of the concepts used in the GNUnet framework are detailed. | ||
145 | The second part describes concepts specific to anonymous file-sharing. | ||
146 | |||
147 | @menu | ||
148 | * Authentication:: | ||
149 | * Accounting to Encourage Resource Sharing:: | ||
150 | * Confidentiality:: | ||
151 | * Anonymity:: | ||
152 | * Deniability:: | ||
153 | * Peer Identities:: | ||
154 | * Zones in the GNU Name System (GNS Zones):: | ||
155 | * Egos:: | ||
156 | @end menu | ||
157 | |||
158 | @cindex Authentication | ||
159 | @node Authentication | ||
160 | @subsection Authentication | ||
161 | |||
162 | Almost all peer-to-peer communications in GNUnet are between mutually | ||
163 | authenticated peers. The authentication works by using ECDHE, that is a | ||
164 | DH (Diffie---Hellman) key exchange using ephemeral elliptic curve | ||
165 | cryptography. The ephemeral ECC (Elliptic Curve Cryptography) keys are | ||
166 | signed using ECDSA (@uref{http://en.wikipedia.org/wiki/ECDSA, ECDSA}). | ||
167 | The shared secret from ECDHE is used to create a pair of session keys | ||
168 | @c FIXME: Long word for HKDF. More FIXMEs: Explain MITM etc. | ||
169 | (using HKDF) which are then used to encrypt the communication between the | ||
170 | two peers using both 256-bit AES (Advanced Encryption Standard) | ||
171 | and 256-bit Twofish (with independently derived secret keys). | ||
172 | As only the two participating hosts know the shared secret, this | ||
173 | authenticates each packet | ||
174 | without requiring signatures each time. GNUnet uses SHA-512 | ||
175 | (Secure Hash Algorithm) hash codes to verify the integrity of messages. | ||
176 | |||
177 | @c FIXME: A while back I got the feedback that I should try and integrate | ||
178 | @c explanation boxes in the long-run. So we could explain | ||
179 | @c "man-in-the-middle" and "man-in-the-middle attacks" and other words | ||
180 | @c which are not common knowledge. MITM is not common knowledge. To be | ||
181 | @c selfcontained, we should be able to explain words and concepts used in | ||
182 | @c a chapter or paragraph without hinting at Wikipedia and other online | ||
183 | @c sources which might not be available or accessible to everyone. | ||
184 | @c On the other hand we could write an introductionary chapter or book | ||
185 | @c that we could then reference in each chapter, which sound like it | ||
186 | @c could be more reusable. | ||
187 | In GNUnet, the identity of a host is its public key. For that reason, | ||
188 | man-in-the-middle attacks will not break the authentication or accounting | ||
189 | goals. Essentially, for GNUnet, the IP of the host has nothing to do with | ||
190 | the identity of the host. As the public key is the only thing that truly | ||
191 | matters, faking an IP, a port or any other property of the underlying | ||
192 | transport protocol is irrelevant. In fact, GNUnet peers can use | ||
193 | multiple IPs (IPv4 and IPv6) on multiple ports --- or even not use the | ||
194 | IP protocol at all (by running directly on layer 2). | ||
195 | @c FIXME: "IP protocol" feels wrong, but could be what people expect, as | ||
196 | @c IP is "the number" and "IP protocol" the protocol itself in general | ||
197 | @c knowledge? | ||
198 | |||
199 | @c NOTE: For consistency we will use @code{HELLO}s throughout this Manual. | ||
200 | GNUnet uses a special type of message to communicate a binding between | ||
201 | public (ECC) keys to their current network address. These messages are | ||
202 | commonly called @code{HELLO}s or @code{peer advertisements}. | ||
203 | They contain the public key of the peer and its current network | ||
204 | addresses for various transport services. | ||
205 | A transport service is a special kind of shared library that | ||
206 | provides (possibly unreliable, out-of-order) message delivery between | ||
207 | peers. | ||
208 | For the UDP and TCP transport services, a network address is an IP and a | ||
209 | port. | ||
210 | GNUnet can also use other transports (HTTP, HTTPS, WLAN, etc.) which use | ||
211 | various other forms of addresses. Note that any node can have many | ||
212 | different active transport services at the same time, | ||
213 | and each of these can have a different addresses. | ||
214 | Binding messages expire after at most a week (the timeout can be | ||
215 | shorter if the user configures the node appropriately). | ||
216 | This expiration ensures that the network will eventually get rid of | ||
217 | outdated advertisements. | ||
218 | @footnote{Ronaldo A. Ferreira, Christian Grothoff, and Paul Ruth. | ||
219 | A Transport Layer Abstraction for Peer-to-Peer Networks | ||
220 | Proceedings of the 3rd International Symposium on Cluster Computing | ||
221 | and the Grid (GRID 2003), 2003. | ||
222 | (@uref{https://gnunet.org/git/bibliography.git/plain/docs/transport.pdf, https://gnunet.org/git/bibliography.git/plain/docs/transport.pdf})} | ||
223 | |||
224 | @cindex Accounting to Encourage Resource Sharing | ||
225 | @node Accounting to Encourage Resource Sharing | ||
226 | @subsection Accounting to Encourage Resource Sharing | ||
227 | |||
228 | Most distributed P2P networks suffer from a lack of defenses or | ||
229 | precautions against attacks in the form of freeloading. | ||
230 | While the intentions of an attacker and a freeloader are different, their | ||
231 | effect on the network is the same; they both render it useless. | ||
232 | Most simple attacks on networks such as @command{Gnutella} | ||
233 | involve flooding the network with traffic, particularly | ||
234 | with queries that are, in the worst case, multiplied by the network. | ||
235 | |||
236 | In order to ensure that freeloaders or attackers have a minimal impact | ||
237 | on the network, GNUnet's file-sharing implementation (@code{FS} tries | ||
238 | to distinguish good (contributing) nodes from malicious (freeloading) | ||
239 | nodes. In GNUnet, every file-sharing node keeps track of the behavior | ||
240 | of every other node it has been in contact with. Many requests | ||
241 | (depending on the application) are transmitted with a priority (or | ||
242 | importance) level. That priority is used to establish how important | ||
243 | the sender believes this request is. If a peer responds to an | ||
244 | important request, the recipient will increase its trust in the | ||
245 | responder: the responder contributed resources. If a peer is too busy | ||
246 | to answer all requests, it needs to prioritize. For that, peers do | ||
247 | not take the priorities of the requests received at face value. | ||
248 | First, they check how much they trust the sender, and depending on | ||
249 | that amount of trust they assign the request a (possibly lower) | ||
250 | effective priority. Then, they drop the requests with the lowest | ||
251 | effective priority to satisfy their resource constraints. This way, | ||
252 | GNUnet's economic model ensures that nodes that are not currently | ||
253 | considered to have a surplus in contributions will not be served if | ||
254 | the network load is high. | ||
255 | @footnote{Christian Grothoff. An Excess-Based Economic Model for Resource | ||
256 | Allocation in Peer-to-Peer Networks. Wirtschaftsinformatik, June 2003. | ||
257 | (@uref{https://gnunet.org/git/bibliography.git/plain/docs/ebe.pdf, https://gnunet.org/git/bibliography.git/plain/docs/ebe.pdf})} | ||
258 | @c 2009? | ||
259 | |||
260 | @cindex Confidentiality | ||
261 | @node Confidentiality | ||
262 | @subsection Confidentiality | ||
263 | |||
264 | Adversaries (malicious, bad actors) outside of GNUnet are not supposed | ||
265 | to know what kind of actions a peer is involved in. Only the specific | ||
266 | neighbor of a peer that is the corresponding sender or recipient of a | ||
267 | message may know its contents, and even then application protocols may | ||
268 | place further restrictions on that knowledge. In order to ensure | ||
269 | confidentiality, GNUnet uses link encryption, that is each message | ||
270 | exchanged between two peers is encrypted using a pair of keys only | ||
271 | known to these two peers. Encrypting traffic like this makes any kind | ||
272 | of traffic analysis much harder. Naturally, for some applications, it | ||
273 | may still be desirable if even neighbors cannot determine the concrete | ||
274 | contents of a message. In GNUnet, this problem is addressed by the | ||
275 | specific application-level protocols. See for example the following | ||
276 | sections @pxref{Anonymity}, @pxref{How file-sharing achieves Anonymity}, | ||
277 | and @pxref{Deniability}. | ||
278 | |||
279 | @cindex Anonymity | ||
280 | @node Anonymity | ||
281 | @subsection Anonymity | ||
282 | 75 | ||
283 | @menu | 76 | For certain applications like file-sharing GNUnet allows participants to trade degrees of anonymity in |
284 | * How file-sharing achieves Anonymity:: | 77 | exchange for increased efficiency. However, it is not possible for any |
285 | @end menu | 78 | user's efficiency requirements to compromise the anonymity |
286 | 79 | of any other user. | |
287 | Providing anonymity for users is the central goal for the anonymous | ||
288 | file-sharing application. Many other design decisions follow in the | ||
289 | footsteps of this requirement. | ||
290 | Anonymity is never absolute. While there are various | ||
291 | scientific metrics@footnote{Claudia Díaz, Stefaan Seys, Joris Claessens, | ||
292 | and Bart Preneel. Towards measuring anonymity. | ||
293 | 2002. | ||
294 | (@uref{https://gnunet.org/git/bibliography.git/plain/docs/article-89.pdf, https://gnunet.org/git/bibliography.git/plain/docs/article-89.pdf})} | ||
295 | that can help quantify the level of anonymity that a given mechanism | ||
296 | provides, there is no such thing as "complete anonymity". | ||
297 | GNUnet's file-sharing implementation allows users to select for each | ||
298 | operation (publish, search, download) the desired level of anonymity. | ||
299 | The metric used is the amount of cover traffic available to hide the | ||
300 | request. | ||
301 | While this metric is not as good as, for example, the theoretical metric | ||
302 | given in scientific metrics@footnote{likewise}, | ||
303 | it is probably the best metric available to a peer with a purely local | ||
304 | view of the world that does not rely on unreliable external information. | ||
305 | The default anonymity level is @code{1}, which uses anonymous routing but | ||
306 | imposes no minimal requirements on cover traffic. It is possible | ||
307 | to forego anonymity when this is not required. The anonymity level of | ||
308 | @code{0} allows GNUnet to use more efficient, non-anonymous routing. | ||
309 | |||
310 | @cindex How file-sharing achieves Anonymity | ||
311 | @node How file-sharing achieves Anonymity | ||
312 | @subsubsection How file-sharing achieves Anonymity | ||
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. | ||
318 | The threat model used for anonymous file sharing in GNUnet assumes that | ||
319 | the adversary is quite powerful. | ||
320 | In particular, we assume that the adversary can see all the traffic on | ||
321 | the Internet. And while we assume that the adversary | ||
322 | can not break our encryption, we assume that the adversary has many | ||
323 | participating nodes in the network and that it can thus see many of the | ||
324 | node-to-node interactions since it controls some of the nodes. | ||
325 | |||
326 | The system tries to achieve anonymity based on the idea that users can be | ||
327 | anonymous if they can hide their actions in the traffic created by other | ||
328 | users. | ||
329 | Hiding actions in the traffic of other users requires participating in the | ||
330 | traffic, bringing back the traditional technique of using indirection and | ||
331 | source rewriting. Source rewriting is required to gain anonymity since | ||
332 | otherwise an adversary could tell if a message originated from a host by | ||
333 | looking at the source address. If all packets look like they originate | ||
334 | from one node, the adversary can not tell which ones originate from that | ||
335 | node and which ones were routed. | ||
336 | Note that in this mindset, any node can decide to break the | ||
337 | source-rewriting paradigm without violating the protocol, as this | ||
338 | only reduces the amount of traffic that a node can hide its own traffic | ||
339 | in. | ||
340 | |||
341 | If we want to hide our actions in the traffic of other nodes, we must make | ||
342 | our traffic indistinguishable from the traffic that we route for others. | ||
343 | As our queries must have us as the receiver of the reply | ||
344 | (otherwise they would be useless), we must put ourselves as the receiver | ||
345 | of replies that actually go to other hosts; in other words, we must | ||
346 | indirect replies. | ||
347 | Unlike other systems, in anonymous file-sharing as implemented on top of | ||
348 | GNUnet we do not have to indirect the replies if we don't think we need | ||
349 | more traffic to hide our own actions. | ||
350 | |||
351 | This increases the efficiency of the network as we can indirect less under | ||
352 | higher load.@footnote{Krista Bennett and Christian Grothoff. | ||
353 | GAP --- practical anonymous networking. In Proceedings of | ||
354 | Designing Privacy Enhancing Technologies, 2003. | ||
355 | (@uref{https://gnunet.org/git/bibliography.git/plain/docs/aff.pdf, https://gnunet.org/git/bibliography.git/plain/docs/aff.pdf})} | ||
356 | |||
357 | @cindex Deniability | ||
358 | @node Deniability | ||
359 | @subsection Deniability | ||
360 | |||
361 | Even if the user that downloads data and the server that provides data are | ||
362 | anonymous, the intermediaries may still be targets. In particular, if the | ||
363 | intermediaries can find out which queries or which content they are | ||
364 | processing, a strong adversary could try to force them to censor | ||
365 | certain materials. | ||
366 | |||
367 | With the file-encoding used by GNUnet's anonymous file-sharing, this | ||
368 | problem does not arise. | ||
369 | The reason is that queries and replies are transmitted in | ||
370 | an encrypted format such that intermediaries cannot tell what the query | ||
371 | is for or what the content is about. Mind that this is not the same | ||
372 | encryption as the link-encryption between the nodes. GNUnet has | ||
373 | encryption on the network layer (link encryption, confidentiality, | ||
374 | authentication) and again on the application layer (provided | ||
375 | by @command{gnunet-publish}, @command{gnunet-download}, | ||
376 | @command{gnunet-search} and @command{gnunet-gtk}). | ||
377 | @footnote{Christian Grothoff, Krista Grothoff, Tzvetan Horozov, | ||
378 | and Jussi T. Lindgren. | ||
379 | An Encoding for Censorship-Resistant Sharing. | ||
380 | 2009. | ||
381 | (@uref{https://gnunet.org/git/bibliography.git/plain/docs/ecrs.pdf, https://gnunet.org/git/bibliography.git/plain/docs/ecrs.pdf})} | ||
382 | |||
383 | @cindex Peer Identities | ||
384 | @node Peer Identities | ||
385 | @subsection Peer Identities | ||
386 | |||
387 | Peer identities are used to identify peers in the network and are unique | ||
388 | for each peer. The identity for a peer is simply its public key, which is | ||
389 | generated along with a private key the peer is started for the first time. | ||
390 | While the identity is binary data, it is often expressed as ASCII string. | ||
391 | For example, the following is a peer identity as you might see it in | ||
392 | various places: | ||
393 | |||
394 | @example | ||
395 | UAT1S6PMPITLBKSJ2DGV341JI6KF7B66AC4JVCN9811NNEGQLUN0 | ||
396 | @end example | ||
397 | |||
398 | @noindent | ||
399 | You can find your peer identity by running @command{gnunet-peerinfo -s}. | ||
400 | |||
401 | @cindex Zones in the GNU Name System (GNS Zones) | ||
402 | @node Zones in the GNU Name System (GNS Zones) | ||
403 | @subsection Zones in the GNU Name System (GNS Zones) | ||
404 | |||
405 | @c FIXME: Explain or link to an explanation of the concept of public keys | ||
406 | @c and private keys. | ||
407 | @c FIXME: Rewrite for the latest GNS changes. | ||
408 | GNS@footnote{Matthias Wachs, Martin Schanzenbach, and Christian Grothoff. | ||
409 | A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name | ||
410 | System. In proceedings of 13th International Conference on Cryptology and | ||
411 | Network Security (CANS 2014). 2014. | ||
412 | @uref{https://gnunet.org/git/bibliography.git/plain/docs/gns2014wachs.pdf, https://gnunet.org/git/bibliography.git/plain/docs/gns2014wachs.pdf}} | ||
413 | zones are similar to those of DNS zones, but instead of a hierarchy of | ||
414 | authorities to governing their use, GNS zones are controlled by a private | ||
415 | key. | ||
416 | When you create a record in a DNS zone, that information is stored in your | ||
417 | nameserver. Anyone trying to resolve your domain then gets pointed | ||
418 | (hopefully) by the centralised authority to your nameserver. | ||
419 | Whereas GNS, being fully decentralized by design, stores that information | ||
420 | in DHT. The validity of the records is assured cryptographically, by | ||
421 | signing them with the private key of the respective zone. | ||
422 | |||
423 | Anyone trying to resolve records in a zone of your domain can then verify | ||
424 | the signature of the records they get from the DHT and be assured that | ||
425 | they are indeed from the respective zone. | ||
426 | To make this work, there is a 1:1 correspondence between zones and | ||
427 | their public-private key pairs. | ||
428 | So when we talk about the owner of a GNS zone, that's really the owner of | ||
429 | the private key. | ||
430 | And a user accessing a zone needs to somehow specify the corresponding | ||
431 | public key first. | ||
432 | |||
433 | @cindex Egos | ||
434 | @node Egos | ||
435 | @subsection Egos | ||
436 | 80 | ||
437 | @c what is the difference between peer identity and egos? It seems | ||
438 | @c like both are linked to public-private key pair. | ||
439 | Egos are your "identities" in GNUnet. Any user can assume multiple | ||
440 | identities, for example to separate their activities online. Egos can | ||
441 | correspond to "pseudonyms" or "real-world identities". Technically an | ||
442 | ego is first of all a key pair of a public- and private-key. | ||