diff options
author | ng0 <ng0@infotropique.org> | 2017-10-20 15:29:28 +0000 |
---|---|---|
committer | ng0 <ng0@infotropique.org> | 2017-10-20 15:29:28 +0000 |
commit | 9b9a2c8b892d62d62d0995a5a792f83e6c67c186 (patch) | |
tree | ce507ef0bfff4bc2b4cbdbebd3d068e7a3e20425 /doc/chapters | |
parent | f7f3f929cc68050880003f3a2a1838910c39e7a3 (diff) | |
download | gnunet-9b9a2c8b892d62d62d0995a5a792f83e6c67c186.tar.gz gnunet-9b9a2c8b892d62d62d0995a5a792f83e6c67c186.zip |
linelength adjustments in 'philosophy'
Diffstat (limited to 'doc/chapters')
-rw-r--r-- | doc/chapters/philosophy.texi | 283 |
1 files changed, 162 insertions, 121 deletions
diff --git a/doc/chapters/philosophy.texi b/doc/chapters/philosophy.texi index d2d1f9289..c4572e6df 100644 --- a/doc/chapters/philosophy.texi +++ b/doc/chapters/philosophy.texi | |||
@@ -1,4 +1,3 @@ | |||
1 | @c *************************************************************************** | ||
2 | @node Philosophy | 1 | @node Philosophy |
3 | @chapter Philosophy | 2 | @chapter Philosophy |
4 | 3 | ||
@@ -23,7 +22,7 @@ generation of decentralized Internet protocols. | |||
23 | @end menu | 22 | @end menu |
24 | 23 | ||
25 | 24 | ||
26 | @c *************************************************************************** | 25 | @cindex Design Goals |
27 | @node Design Goals | 26 | @node Design Goals |
28 | @section Design Goals | 27 | @section Design Goals |
29 | 28 | ||
@@ -31,85 +30,100 @@ These are the core GNUnet design goals, in order of relative importance: | |||
31 | 30 | ||
32 | @itemize | 31 | @itemize |
33 | @item GNUnet must be implemented as free software. | 32 | @item GNUnet must be implemented as free software. |
34 | @item GNUnet must only disclose the minimal amount of information necessary. | 33 | @item GNUnet must only disclose the minimal amount of information |
35 | @item GNUnet must be decentralised and survive Byzantine failures in any position in the network. | 34 | necessary. |
36 | @item GNUnet must make it explicit to the user which entities must be trustworthy when establishing secured communications. | 35 | @item GNUnet must be decentralised and survive Byzantine failures in any |
37 | @item GNUnet must use compartmentalization to protect sensitive information. | 36 | position in the network. |
37 | @item GNUnet must make it explicit to the user which entities must be | ||
38 | trustworthy when establishing secured communications. | ||
39 | @item GNUnet must use compartmentalization to protect sensitive | ||
40 | information. | ||
38 | @item GNUnet must be open and permit new peers to join. | 41 | @item GNUnet must be open and permit new peers to join. |
39 | @item GNUnet must be self-organizing and not depend on administrators. | 42 | @item GNUnet must be self-organizing and not depend on administrators. |
40 | @item GNUnet must support a diverse range of applications and devices. | 43 | @item GNUnet must support a diverse range of applications and devices. |
41 | @item The GNUnet architecture must be cost effective. | 44 | @item The GNUnet architecture must be cost effective. |
42 | @item GNUnet must provide incentives for peers to contribute more resources than they consume. | 45 | @item GNUnet must provide incentives for peers to contribute more |
46 | resources than they consume. | ||
43 | @end itemize | 47 | @end itemize |
44 | 48 | ||
45 | 49 | ||
50 | @cindex Security and Privacy | ||
46 | @node Security & Privacy | 51 | @node Security & Privacy |
47 | @section Security & Privacy | 52 | @section Security & Privacy |
48 | 53 | ||
49 | GNUnet's primary design goals are to protect the privacy of its users and to | 54 | GNUnet's primary design goals are to protect the privacy of its users and |
50 | guard itself against attacks or abuse. GNUnet does not have any mechanisms | 55 | to guard itself against attacks or abuse. |
51 | to control, track or censor users. Instead, the GNUnet protocols aim to make | 56 | GNUnet does not have any mechanisms to control, track or censor users. |
52 | it as hard as possible to find out what is happening on the network or to | 57 | Instead, the GNUnet protocols aim to make it as hard as possible to |
53 | disrupt operations. | 58 | find out what is happening on the network or to disrupt operations. |
54 | 59 | ||
60 | @cindex Versatility | ||
55 | @node Versatility | 61 | @node Versatility |
56 | @section Versatility | 62 | @section Versatility |
57 | 63 | ||
58 | We call GNUnet a peer-to-peer framework because we want to support many | 64 | We call GNUnet a peer-to-peer framework because we want to support many |
59 | different forms of peer-to-peer applications. GNUnet uses a plugin | 65 | different forms of peer-to-peer applications. GNUnet uses a plugin |
60 | architecture to make the system extensible and to encourage code reuse. | 66 | architecture to make the system extensible and to encourage code reuse. |
61 | While the first versions of the system only supported anonymous file-sharing, | 67 | While the first versions of the system only supported anonymous |
62 | other applications are being worked on and more will hopefully follow in the | 68 | file-sharing, other applications are being worked on and more will |
63 | future. A powerful synergy regarding anonymity services is created by a large | 69 | hopefully follow in the future. |
70 | A powerful synergy regarding anonymity services is created by a large | ||
64 | community utilizing many diverse applications over the same software | 71 | community utilizing many diverse applications over the same software |
65 | infrastructure. The reason is that link encryption hides the specifics | 72 | infrastructure. The reason is that link encryption hides the specifics |
66 | of the traffic for non-participating observers. This way, anonymity can | 73 | of the traffic for non-participating observers. This way, anonymity can |
67 | get stronger with additional (GNUnet) traffic, even if the additional | 74 | get stronger with additional (GNUnet) traffic, even if the additional |
68 | traffic is not related to anonymous communication. Increasing anonymity is | 75 | traffic is not related to anonymous communication. Increasing anonymity is |
69 | the primary reason why GNUnet is developed to become a peer-to-peer | 76 | the primary reason why GNUnet is developed to become a peer-to-peer |
70 | framework where many applications share the lower layers of an increasingly | 77 | framework where many applications share the lower layers of an |
71 | complex protocol stack. If merging traffic to hinder traffic analysis was | 78 | increasingly complex protocol stack. |
72 | not important, we could have just developed a dozen stand-alone applications | 79 | If merging traffic to hinder traffic analysis was not important, |
80 | we could have just developed a dozen stand-alone applications | ||
73 | and a few shared libraries. | 81 | and a few shared libraries. |
74 | 82 | ||
83 | @cindex Practicality | ||
75 | @node Practicality | 84 | @node Practicality |
76 | @section Practicality | 85 | @section Practicality |
77 | 86 | ||
78 | GNUnet allows participants to trade various amounts of security in exchange | 87 | GNUnet allows participants to trade various amounts of security in |
79 | for increased efficiency. However, it is not possible for any user's security | 88 | exchange for increased efficiency. However, it is not possible for any |
80 | and efficiency requirements to compromise the security and efficiency of | 89 | user's security and efficiency requirements to compromise the security |
81 | any other user. | 90 | and efficiency of any other user. |
82 | 91 | ||
83 | For GNUnet, efficiency is not paramount. If there is a more secure and still | 92 | For GNUnet, efficiency is not paramount. If there is a more secure and |
84 | practical approach, we would choose to take the more secure alternative. | 93 | still practical approach, we would choose to take the more secure |
85 | @command{telnet} is more efficient than @command{ssh}, yet it is obsolete. | 94 | alternative. @command{telnet} is more efficient than @command{ssh}, yet |
95 | it is obsolete. | ||
86 | Hardware gets faster, and code can be optimized. Fixing security issues as | 96 | Hardware gets faster, and code can be optimized. Fixing security issues as |
87 | an afterthought is much harder. | 97 | an afterthought is much harder. |
88 | 98 | ||
89 | While security is paramount, practicability is still a requirement. The most | 99 | While security is paramount, practicability is still a requirement. |
90 | secure system is always the one that nobody can use. Similarly, any | 100 | The most secure system is always the one that nobody can use. |
91 | anonymous system that is extremely inefficient will only find few users. | 101 | Similarly, any anonymous system that is extremely inefficient will only |
102 | find few users. | ||
92 | However, good anonymity requires a large and diverse user base. Since | 103 | However, good anonymity requires a large and diverse user base. Since |
93 | individual security requirements may vary, the only good solution here is to | 104 | individual security requirements may vary, the only good solution here is |
94 | allow individuals to trade-off security and efficiency. The primary challenge | 105 | to allow individuals to trade-off security and efficiency. |
95 | in allowing this is to ensure that the economic incentives work properly. | 106 | The primary challenge in allowing this is to ensure that the economic |
107 | incentives work properly. | ||
96 | In particular, this means that it must be impossible for a user to gain | 108 | In particular, this means that it must be impossible for a user to gain |
97 | security at the expense of other users. Many designs (e.g. anonymity via | 109 | security at the expense of other users. Many designs (e.g. anonymity via |
98 | broadcast) fail to give users an incentive to choose a less secure but more | 110 | broadcast) fail to give users an incentive to choose a less secure but |
99 | efficient mode of operation. GNUnet should avoid where ever possible to | 111 | more efficient mode of operation. |
100 | rely on protocols that will only work if the participants are benevolent. | 112 | GNUnet should avoid where ever possible to rely on protocols that will |
113 | only work if the participants are benevolent. | ||
101 | While some designs have had widespread success while relying on parties | 114 | While some designs have had widespread success while relying on parties |
102 | to observe a protocol that may be sub-optimal for the individuals (e.g. | 115 | to observe a protocol that may be sub-optimal for the individuals (e.g. |
103 | TCP Nagle), a protocol that ensures that individual goals never conflict | 116 | TCP Nagle), a protocol that ensures that individual goals never conflict |
104 | with the goals of the group is always preferable. | 117 | with the goals of the group is always preferable. |
105 | 118 | ||
119 | @cindex Key Concepts | ||
106 | @node Key Concepts | 120 | @node Key Concepts |
107 | @section Key Concepts | 121 | @section Key Concepts |
108 | 122 | ||
109 | In this section, the fundamental concepts of GNUnet are explained. Most of | 123 | In this section, the fundamental concepts of GNUnet are explained. |
110 | them are also described in our research papers. First, some of the concepts | 124 | Most of them are also described in our research papers. |
111 | used in the GNUnet framework are detailed. The second part describes concepts | 125 | First, some of the concepts used in the GNUnet framework are detailed. |
112 | specific to anonymous file-sharing. | 126 | The second part describes concepts specific to anonymous file-sharing. |
113 | 127 | ||
114 | @menu | 128 | @menu |
115 | * Authentication:: | 129 | * Authentication:: |
@@ -122,6 +136,7 @@ specific to anonymous file-sharing. | |||
122 | * Egos:: | 136 | * Egos:: |
123 | @end menu | 137 | @end menu |
124 | 138 | ||
139 | @cindex Authentication | ||
125 | @node Authentication | 140 | @node Authentication |
126 | @subsection Authentication | 141 | @subsection Authentication |
127 | 142 | ||
@@ -148,64 +163,75 @@ IP protocol at all (by running directly on layer 2). | |||
148 | GNUnet uses a special type of message to communicate a binding between | 163 | GNUnet uses a special type of message to communicate a binding between |
149 | public (ECC) keys to their current network address. These messages are | 164 | public (ECC) keys to their current network address. These messages are |
150 | commonly called HELLOs or peer advertisements. They contain the public key | 165 | commonly called HELLOs or peer advertisements. They contain the public key |
151 | of the peer and its current network addresses for various transport services. | 166 | of the peer and its current network addresses for various transport |
167 | services. | ||
152 | A transport service is a special kind of shared library that | 168 | A transport service is a special kind of shared library that |
153 | provides (possibly unreliable, out-of-order) message delivery between peers. | 169 | provides (possibly unreliable, out-of-order) message delivery between |
154 | For the UDP and TCP transport services, a network address is an IP and a port. | 170 | peers. |
171 | For the UDP and TCP transport services, a network address is an IP and a | ||
172 | port. | ||
155 | GNUnet can also use other transports (HTTP, HTTPS, WLAN, etc.) which use | 173 | GNUnet can also use other transports (HTTP, HTTPS, WLAN, etc.) which use |
156 | various other forms of addresses. Note that any node can have many different | 174 | various other forms of addresses. Note that any node can have many |
175 | different | ||
157 | active transport services at the same time, and each of these can have a | 176 | active transport services at the same time, and each of these can have a |
158 | different addresses. Binding messages expire after at most a week (the | 177 | different addresses. Binding messages expire after at most a week (the |
159 | timeout can be shorter if the user configures the node appropriately). This | 178 | timeout can be shorter if the user configures the node appropriately). |
160 | expiration ensures that the network will eventually get rid of outdated | 179 | This expiration ensures that the network will eventually get rid of |
161 | advertisements. | 180 | outdated advertisements.@footnote{More details can be found in |
162 | @footnote{More details can be found in @uref{https://gnunet.org/transports, A Transport Layer Abstraction for Peer-to-Peer Networks}} | 181 | @uref{https://gnunet.org/transports, A Transport Layer Abstraction for |
182 | Peer-to-Peer Networks}} | ||
163 | 183 | ||
184 | @cindex Resource Sharing | ||
164 | @node Accounting to Encourage Resource Sharing | 185 | @node Accounting to Encourage Resource Sharing |
165 | @subsection Accounting to Encourage Resource Sharing | 186 | @subsection Accounting to Encourage Resource Sharing |
166 | 187 | ||
167 | Most distributed P2P networks suffer from a lack of defenses or precautions | 188 | Most distributed P2P networks suffer from a lack of defenses or |
168 | against attacks in the form of freeloading. While the intentions of an | 189 | precautions against attacks in the form of freeloading. |
169 | attacker and a freeloader are different, their effect on the network is the | 190 | While the intentions of an attacker and a freeloader are different, their |
170 | same; they both render it useless. Most simple attacks on networks such as | 191 | effect on the network is the same; they both render it useless. |
171 | Gnutella involve flooding the network with traffic, particularly with | 192 | Most simple attacks on networks such as Gnutella involve flooding the |
172 | queries that are, in the worst case, multiplied by the network. | 193 | network with traffic, particularly with queries that are, in the worst |
194 | case, multiplied by the network. | ||
173 | 195 | ||
174 | In order to ensure that freeloaders or attackers have a minimal impact on the | 196 | In order to ensure that freeloaders or attackers have a minimal impact on |
175 | network, GNUnet's file-sharing implementation tries to distinguish | 197 | the network, GNUnet's file-sharing implementation tries to distinguish |
176 | good (contributing) nodes from malicious (freeloading) nodes. In GNUnet, | 198 | good (contributing) nodes from malicious (freeloading) nodes. In GNUnet, |
177 | every file-sharing node keeps track of the behavior of every other node it | 199 | every file-sharing node keeps track of the behavior of every other node it |
178 | has been in contact with. Many requests (depending on the application) are | 200 | has been in contact with. Many requests (depending on the application) are |
179 | transmitted with a priority (or importance) level. That priority is used to | 201 | transmitted with a priority (or importance) level. That priority is used |
180 | establish how important the sender believes this request is. If a peer | 202 | to establish how important the sender believes this request is. If a peer |
181 | responds to an important request, the recipient will increase its trust in the | 203 | responds to an important request, the recipient will increase its trust in |
182 | responder: the responder contributed resources. If a peer is too busy to | 204 | the responder: the responder contributed resources. If a peer is too busy |
183 | answer all requests, it needs to prioritize. For that, peers to not take the | 205 | to answer all requests, it needs to prioritize. For that, peers to not |
184 | priorities of the requests received at face value. First, they check how much | 206 | take the priorities of the requests received at face value. |
185 | they trust the sender, and depending on that amount of trust they assign the | 207 | First, they check how much they trust the sender, and depending on that |
186 | request a (possibly lower) effective priority. Then, they drop the requests | 208 | amount of trust they assign the request a (possibly lower) effective |
187 | with the lowest effective priority to satisfy their resource constraints. This | 209 | priority. Then, they drop the requests with the lowest effective priority |
188 | way, GNUnet's economic model ensures that nodes that are not currently | 210 | to satisfy their resource constraints. This way, GNUnet's economic model |
189 | considered to have a surplus in contributions will not be served if the | 211 | ensures that nodes that are not currently considered to have a surplus in |
190 | network load is high. | 212 | contributions will not be served if the network load is high.@footnote{Mor |
191 | @footnote{More details can be found in @uref{https://gnunet.org/ebe, this paper}} | 213 | e details can be found in @uref{https://gnunet.org/ebe, this paper}} |
192 | 214 | ||
215 | @cindex Confidentiality | ||
193 | @node Confidentiality | 216 | @node Confidentiality |
194 | @subsection Confidentiality | 217 | @subsection Confidentiality |
195 | 218 | ||
196 | Adversaries outside of GNUnet are not supposed to know what kind of actions a | 219 | Adversaries outside of GNUnet are not supposed to know what kind of |
197 | peer is involved in. Only the specific neighbor of a peer that is the | 220 | actions a peer is involved in. Only the specific neighbor of a peer that |
198 | corresponding sender or recipient of a message may know its contents, and even | 221 | is the corresponding sender or recipient of a message may know its |
199 | then application protocols may place further restrictions on that knowledge. | 222 | contents, and even then application protocols may place further |
200 | In order to ensure confidentiality, GNUnet uses link encryption, that is each | 223 | restrictions on that knowledge. |
201 | message exchanged between two peers is encrypted using a pair of keys only | 224 | In order to ensure confidentiality, GNUnet uses link encryption, that is |
202 | known to these two peers. Encrypting traffic like this makes any kind of | 225 | each message exchanged between two peers is encrypted using a pair of |
203 | traffic analysis much harder. Naturally, for some applications, it may still | 226 | keys only known to these two peers. |
204 | be desirable if even neighbors cannot determine the concrete contents of a | 227 | Encrypting traffic like this makes any kind of traffic analysis much |
205 | message. In GNUnet, this problem is addressed by the specific | 228 | harder. Naturally, for some applications, it may still be desirable if |
206 | application-level protocols (see for example, deniability and anonymity in | 229 | even neighbors cannot determine the concrete contents of a message. |
207 | anonymous file sharing). | 230 | In GNUnet, this problem is addressed by the specific application-level |
208 | 231 | protocols (see for example, deniability and anonymity in anonymous file | |
232 | sharing). | ||
233 | |||
234 | @cindex Anonymity | ||
209 | @node Anonymity | 235 | @node Anonymity |
210 | @subsection Anonymity | 236 | @subsection Anonymity |
211 | 237 | ||
@@ -214,14 +240,16 @@ anonymous file sharing). | |||
214 | @end menu | 240 | @end menu |
215 | 241 | ||
216 | Providing anonymity for users is the central goal for the anonymous | 242 | Providing anonymity for users is the central goal for the anonymous |
217 | file-sharing application. Many other design decisions follow in the footsteps | 243 | file-sharing application. Many other design decisions follow in the |
218 | of this requirement. Anonymity is never absolute. While there are various | 244 | footsteps of this requirement. |
245 | Anonymity is never absolute. While there are various | ||
219 | @uref{https://gnunet.org/anonymity_metric, scientific metrics} that can | 246 | @uref{https://gnunet.org/anonymity_metric, scientific metrics} that can |
220 | help quantify the level of anonymity that a given mechanism provides, | 247 | help quantify the level of anonymity that a given mechanism provides, |
221 | there is no such thing as complete anonymity. | 248 | there is no such thing as complete anonymity. |
222 | GNUnet's file-sharing implementation allows users to select for each | 249 | GNUnet's file-sharing implementation allows users to select for each |
223 | operation (publish, search, download) the desired level of anonymity. | 250 | operation (publish, search, download) the desired level of anonymity. |
224 | The metric used is the amount of cover traffic available to hide the request. | 251 | The metric used is the amount of cover traffic available to hide the |
252 | request. | ||
225 | While this metric is not as good as, for example, the theoretical metric | 253 | While this metric is not as good as, for example, the theoretical metric |
226 | given in @uref{https://gnunet.org/anonymity_metric, scientific metrics}, | 254 | given in @uref{https://gnunet.org/anonymity_metric, scientific metrics}, |
227 | it is probably the best metric available to a peer with a purely local | 255 | it is probably the best metric available to a peer with a purely local |
@@ -236,10 +264,12 @@ allows GNUnet to use more efficient, non-anonymous routing. | |||
236 | 264 | ||
237 | Contrary to other designs, we do not believe that users achieve strong | 265 | Contrary to other designs, we do not believe that users achieve strong |
238 | anonymity just because their requests are obfuscated by a couple of | 266 | anonymity just because their requests are obfuscated by a couple of |
239 | indirections. This is not sufficient if the adversary uses traffic analysis. | 267 | indirections. This is not sufficient if the adversary uses traffic |
240 | The threat model used for anonymous file sharing in GNUnet assumes that the | 268 | analysis. |
241 | adversary is quite powerful. In particular, we assume that the adversary can | 269 | The threat model used for anonymous file sharing in GNUnet assumes that |
242 | see all the traffic on the Internet. And while we assume that the adversary | 270 | the adversary is quite powerful. |
271 | In particular, we assume that the adversary can see all the traffic on | ||
272 | the Internet. And while we assume that the adversary | ||
243 | can not break our encryption, we assume that the adversary has many | 273 | can not break our encryption, we assume that the adversary has many |
244 | participating nodes in the network and that it can thus see many of the | 274 | participating nodes in the network and that it can thus see many of the |
245 | node-to-node interactions since it controls some of the nodes. | 275 | node-to-node interactions since it controls some of the nodes. |
@@ -251,25 +281,29 @@ Hiding actions in the traffic of other users requires participating in the | |||
251 | traffic, bringing back the traditional technique of using indirection and | 281 | traffic, bringing back the traditional technique of using indirection and |
252 | source rewriting. Source rewriting is required to gain anonymity since | 282 | source rewriting. Source rewriting is required to gain anonymity since |
253 | otherwise an adversary could tell if a message originated from a host by | 283 | otherwise an adversary could tell if a message originated from a host by |
254 | looking at the source address. If all packets look like they originate from | 284 | looking at the source address. If all packets look like they originate |
255 | a node, the adversary can not tell which ones originate from that node and | 285 | from a node, the adversary can not tell which ones originate from that |
256 | which ones were routed. Note that in this mindset, any node can decide to | 286 | node and which ones were routed. |
257 | break the source-rewriting paradigm without violating the protocol, as this | 287 | Note that in this mindset, any node can decide to break the |
258 | only reduces the amount of traffic that a node can hide its own traffic in. | 288 | source-rewriting paradigm without violating the protocol, as this |
289 | only reduces the amount of traffic that a node can hide its own traffic | ||
290 | in. | ||
259 | 291 | ||
260 | If we want to hide our actions in the traffic of other nodes, we must make | 292 | If we want to hide our actions in the traffic of other nodes, we must make |
261 | our traffic indistinguishable from the traffic that we route for others. As | 293 | our traffic indistinguishable from the traffic that we route for others. |
262 | our queries must have us as the receiver of the reply (otherwise they would | 294 | As our queries must have us as the receiver of the reply |
263 | be useless), we must put ourselves as the receiver of replies that actually | 295 | (otherwise they would be useless), we must put ourselves as the receiver |
264 | go to other hosts; in other words, we must indirect replies. Unlike other | 296 | of replies that actually go to other hosts; in other words, we must |
265 | systems, in anonymous file-sharing as implemented on top of GNUnet we do not | 297 | indirect replies. |
266 | have to indirect the replies if we don't think we need more traffic to hide | 298 | Unlike other systems, in anonymous file-sharing as implemented on top of |
267 | our own actions. | 299 | GNUnet we do not have to indirect the replies if we don't think we need |
300 | more traffic to hide our own actions. | ||
268 | 301 | ||
269 | This increases the efficiency of the network as we can indirect less under | 302 | This increases the efficiency of the network as we can indirect less under |
270 | higher load. | 303 | higher load.@footnote{More details can be found in @uref{https://gnunet. |
271 | @footnote{More details can be found in @uref{https://gnunet.org/gap, this paper}} | 304 | org/gap, this paper}} |
272 | 305 | ||
306 | @cindex Deniability | ||
273 | @node Deniability | 307 | @node Deniability |
274 | @subsection Deniability | 308 | @subsection Deniability |
275 | 309 | ||
@@ -279,49 +313,56 @@ intermediaries can find out which queries or which content they are | |||
279 | processing, a strong adversary could try to force them to censor | 313 | processing, a strong adversary could try to force them to censor |
280 | certain materials. | 314 | certain materials. |
281 | 315 | ||
282 | With the file-encoding used by GNUnet's anonymous file-sharing, this problem | 316 | With the file-encoding used by GNUnet's anonymous file-sharing, this |
283 | does not arise. The reason is that queries and replies are transmitted in | 317 | problem does not arise. |
318 | The reason is that queries and replies are transmitted in | ||
284 | an encrypted format such that intermediaries cannot tell what the query | 319 | an encrypted format such that intermediaries cannot tell what the query |
285 | is for or what the content is about. Mind that this is not the same | 320 | is for or what the content is about. Mind that this is not the same |
286 | encryption as the link-encryption between the nodes. GNUnet has | 321 | encryption as the link-encryption between the nodes. GNUnet has |
287 | encryption on the network layer (link encryption, confidentiality, | 322 | encryption on the network layer (link encryption, confidentiality, |
288 | authentication) and again on the application layer (provided | 323 | authentication) and again on the application layer (provided |
289 | by @command{gnunet-publish}, @command{gnunet-download}, @command{gnunet-search} | 324 | by @command{gnunet-publish}, @command{gnunet-download}, |
290 | and @command{gnunet-gtk}). | 325 | @command{gnunet-search} and @command{gnunet-gtk}).@footnote{More details |
291 | @footnote{More details can be found @uref{https://gnunet.org/encoding, here}} | 326 | can be found @uref{https://gnunet.org/encoding, here}} |
292 | 327 | ||
328 | @cindex Peer Identities | ||
293 | @node Peer Identities | 329 | @node Peer Identities |
294 | @subsection Peer Identities | 330 | @subsection Peer Identities |
295 | 331 | ||
296 | Peer identities are used to identify peers in the network and are unique for | 332 | Peer identities are used to identify peers in the network and are unique |
297 | each peer. The identity for a peer is simply its public key, which is | 333 | for each peer. The identity for a peer is simply its public key, which is |
298 | generated along with a private key the peer is started for the first time. | 334 | generated along with a private key the peer is started for the first time. |
299 | While the identity is binary data, it is often expressed as ASCII string. | 335 | While the identity is binary data, it is often expressed as ASCII string. |
300 | For example, the following is a peer identity as you might see it in | 336 | For example, the following is a peer identity as you might see it in |
301 | various places: @code{ UAT1S6PMPITLBKSJ2DGV341JI6KF7B66AC4JVCN9811NNEGQLUN0} | 337 | various places: |
338 | @code{ UAT1S6PMPITLBKSJ2DGV341JI6KF7B66AC4JVCN9811NNEGQLUN0} | ||
302 | 339 | ||
303 | You can find your peer identity by running @command{gnunet-peerinfo -s}. | 340 | You can find your peer identity by running @command{gnunet-peerinfo -s}. |
304 | 341 | ||
342 | @cindex GNS Zones | ||
305 | @node Zones in the GNU Name System (GNS Zones) | 343 | @node Zones in the GNU Name System (GNS Zones) |
306 | @subsection Zones in the GNU Name System (GNS Zones) | 344 | @subsection Zones in the GNU Name System (GNS Zones) |
307 | 345 | ||
308 | GNS zones are similar to those of DNS zones, but instead of a hierarchy of | 346 | GNS zones are similar to those of DNS zones, but instead of a hierarchy of |
309 | authorities to governing their use, GNS zones are controlled by a private key. | 347 | authorities to governing their use, GNS zones are controlled by a private |
348 | key. | ||
310 | When you create a record in a DNS zone, that information stored in your | 349 | When you create a record in a DNS zone, that information stored in your |
311 | nameserver. Anyone trying to resolve your domain then gets pointed (hopefully) | 350 | nameserver. Anyone trying to resolve your domain then gets pointed |
312 | by the centralised authority to your nameserver. Whereas GNS, being | 351 | (hopefully) by the centralised authority to your nameserver. |
313 | decentralised by design, stores that information in DHT. The validity of the | 352 | Whereas GNS, being decentralised by design, stores that information in |
314 | records is assured cryptographically, by signing them with the private key of | 353 | DHT. The validity of the records is assured cryptographically, by |
315 | the respective zone. | 354 | signing them with the private key of the respective zone. |
316 | 355 | ||
317 | Anyone trying to resolve records in a zone your domain can then verify the | 356 | Anyone trying to resolve records in a zone your domain can then verify the |
318 | signature on the records they get from the DHT and be assured that they are | 357 | signature on the records they get from the DHT and be assured that they |
319 | indeed from the respective zone. To make this work, there is a 1:1 | 358 | are indeed from the respective zone. To make this work, there is a 1:1 |
320 | correspondence between zones and their public-private key pairs. So when we | 359 | correspondence between zones and their public-private key pairs. |
321 | talk about the owner of a GNS zone, that's really the owner of the private | 360 | So when we talk about the owner of a GNS zone, that's really the owner of |
322 | key. And a user accessing a zone needs to somehow specify the corresponding | 361 | the private key. |
362 | And a user accessing a zone needs to somehow specify the corresponding | ||
323 | public key first. | 363 | public key first. |
324 | 364 | ||
365 | @cindex Egos | ||
325 | @node Egos | 366 | @node Egos |
326 | @subsection Egos | 367 | @subsection Egos |
327 | 368 | ||