diff options
Diffstat (limited to 'doc/documentation')
-rw-r--r-- | doc/documentation/chapters/philosophy.texi | 98 |
1 files changed, 56 insertions, 42 deletions
diff --git a/doc/documentation/chapters/philosophy.texi b/doc/documentation/chapters/philosophy.texi index 681d5acc3..386bbdf40 100644 --- a/doc/documentation/chapters/philosophy.texi +++ b/doc/documentation/chapters/philosophy.texi | |||
@@ -174,6 +174,16 @@ authenticates each packet | |||
174 | without requiring signatures each time. GNUnet uses SHA-512 | 174 | without requiring signatures each time. GNUnet uses SHA-512 |
175 | (Secure Hash Algorithm) hash codes to verify the integrity of messages. | 175 | (Secure Hash Algorithm) hash codes to verify the integrity of messages. |
176 | 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. | ||
177 | In GNUnet, the identity of a host is its public key. For that reason, | 187 | In GNUnet, the identity of a host is its public key. For that reason, |
178 | man-in-the-middle attacks will not break the authentication or accounting | 188 | man-in-the-middle attacks will not break the authentication or accounting |
179 | goals. Essentially, for GNUnet, the IP of the host has nothing to do with | 189 | goals. Essentially, for GNUnet, the IP of the host has nothing to do with |
@@ -182,11 +192,14 @@ matters, faking an IP, a port or any other property of the underlying | |||
182 | transport protocol is irrelevant. In fact, GNUnet peers can use | 192 | transport protocol is irrelevant. In fact, GNUnet peers can use |
183 | multiple IPs (IPv4 and IPv6) on multiple ports --- or even not use the | 193 | multiple IPs (IPv4 and IPv6) on multiple ports --- or even not use the |
184 | IP protocol at all (by running directly on layer 2). | 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? | ||
185 | 198 | ||
186 | @c NOTE: For consistency we will use @code{HELLO}s throughout this Manual. | 199 | @c NOTE: For consistency we will use @code{HELLO}s throughout this Manual. |
187 | GNUnet uses a special type of message to communicate a binding between | 200 | GNUnet uses a special type of message to communicate a binding between |
188 | public (ECC) keys to their current network address. These messages are | 201 | public (ECC) keys to their current network address. These messages are |
189 | commonly called @code{HELLO}s or peer advertisements. | 202 | commonly called @code{HELLO}s or @code{peer advertisements}. |
190 | They contain the public key of the peer and its current network | 203 | They contain the public key of the peer and its current network |
191 | addresses for various transport services. | 204 | addresses for various transport services. |
192 | A transport service is a special kind of shared library that | 205 | A transport service is a special kind of shared library that |
@@ -220,25 +233,25 @@ Most simple attacks on networks such as @command{Gnutella} | |||
220 | involve flooding the network with traffic, particularly | 233 | involve flooding the network with traffic, particularly |
221 | with queries that are, in the worst case, multiplied by the network. | 234 | with queries that are, in the worst case, multiplied by the network. |
222 | 235 | ||
223 | In order to ensure that freeloaders or attackers have a minimal impact on | 236 | In order to ensure that freeloaders or attackers have a minimal impact |
224 | the network, GNUnet's file-sharing implementation tries to distinguish | 237 | on the network, GNUnet's file-sharing implementation (@code{FS} tries |
225 | good (contributing) nodes from malicious (freeloading) nodes. In GNUnet, | 238 | to distinguish good (contributing) nodes from malicious (freeloading) |
226 | every file-sharing node keeps track of the behavior of every other node it | 239 | nodes. In GNUnet, every file-sharing node keeps track of the behavior |
227 | has been in contact with. Many requests (depending on the application) | 240 | of every other node it has been in contact with. Many requests |
228 | are transmitted with a priority (or importance) level. | 241 | (depending on the application) are transmitted with a priority (or |
229 | That priority is used to establish how important the sender believes | 242 | importance) level. That priority is used to establish how important |
230 | this request is. If a peer responds to an important request, the | 243 | the sender believes this request is. If a peer responds to an |
231 | recipient will increase its trust in the responder: | 244 | important request, the recipient will increase its trust in the |
232 | the responder contributed resources. | 245 | responder: the responder contributed resources. If a peer is too busy |
233 | If a peer is too busy to answer all requests, it needs to prioritize. | 246 | to answer all requests, it needs to prioritize. For that, peers do |
234 | For that, peers do not take the priorities of the requests received at | 247 | not take the priorities of the requests received at face value. |
235 | face value. | 248 | First, they check how much they trust the sender, and depending on |
236 | First, they check how much they trust the sender, and depending on that | 249 | that amount of trust they assign the request a (possibly lower) |
237 | amount of trust they assign the request a (possibly lower) effective | 250 | effective priority. Then, they drop the requests with the lowest |
238 | priority. Then, they drop the requests with the lowest effective priority | 251 | effective priority to satisfy their resource constraints. This way, |
239 | to satisfy their resource constraints. This way, GNUnet's economic model | 252 | GNUnet's economic model ensures that nodes that are not currently |
240 | ensures that nodes that are not currently considered to have a surplus in | 253 | considered to have a surplus in contributions will not be served if |
241 | contributions will not be served if the network load is high. | 254 | the network load is high. |
242 | @footnote{Christian Grothoff. An Excess-Based Economic Model for Resource | 255 | @footnote{Christian Grothoff. An Excess-Based Economic Model for Resource |
243 | Allocation in Peer-to-Peer Networks. Wirtschaftsinformatik, June 2003. | 256 | Allocation in Peer-to-Peer Networks. Wirtschaftsinformatik, June 2003. |
244 | (@uref{https://gnunet.org/git/bibliography.git/plain/docs/ebe.pdf, https://gnunet.org/git/bibliography.git/plain/docs/ebe.pdf})} | 257 | (@uref{https://gnunet.org/git/bibliography.git/plain/docs/ebe.pdf, https://gnunet.org/git/bibliography.git/plain/docs/ebe.pdf})} |
@@ -248,20 +261,20 @@ Allocation in Peer-to-Peer Networks. Wirtschaftsinformatik, June 2003. | |||
248 | @node Confidentiality | 261 | @node Confidentiality |
249 | @subsection Confidentiality | 262 | @subsection Confidentiality |
250 | 263 | ||
251 | Adversaries outside of GNUnet are not supposed to know what kind of | 264 | Adversaries (malicious, bad actors) outside of GNUnet are not supposed |
252 | actions a peer is involved in. Only the specific neighbor of a peer that | 265 | to know what kind of actions a peer is involved in. Only the specific |
253 | is the corresponding sender or recipient of a message may know its | 266 | neighbor of a peer that is the corresponding sender or recipient of a |
254 | contents, and even then application protocols may place further | 267 | message may know its contents, and even then application protocols may |
255 | restrictions on that knowledge. | 268 | place further restrictions on that knowledge. In order to ensure |
256 | In order to ensure confidentiality, GNUnet uses link encryption, that is | 269 | confidentiality, GNUnet uses link encryption, that is each message |
257 | each message exchanged between two peers is encrypted using a pair of | 270 | exchanged between two peers is encrypted using a pair of keys only |
258 | keys only known to these two peers. | 271 | known to these two peers. Encrypting traffic like this makes any kind |
259 | Encrypting traffic like this makes any kind of traffic analysis much | 272 | of traffic analysis much harder. Naturally, for some applications, it |
260 | harder. Naturally, for some applications, it may still be desirable if | 273 | may still be desirable if even neighbors cannot determine the concrete |
261 | even neighbors cannot determine the concrete contents of a message. | 274 | contents of a message. In GNUnet, this problem is addressed by the |
262 | In GNUnet, this problem is addressed by the specific application-level | 275 | specific application-level protocols. See for example the following |
263 | protocols (see for example, deniability and anonymity in anonymous file | 276 | sections @pxref{Anonymity}, @pxref{How file-sharing achieves Anonymity}, |
264 | sharing). | 277 | and @pxref{Deniability}. |
265 | 278 | ||
266 | @cindex Anonymity | 279 | @cindex Anonymity |
267 | @node Anonymity | 280 | @node Anonymity |
@@ -280,7 +293,7 @@ and Bart Preneel. Towards measuring anonymity. | |||
280 | 2002. | 293 | 2002. |
281 | (@uref{https://gnunet.org/git/bibliography.git/plain/docs/article-89.pdf, https://gnunet.org/git/bibliography.git/plain/docs/article-89.pdf})} | 294 | (@uref{https://gnunet.org/git/bibliography.git/plain/docs/article-89.pdf, https://gnunet.org/git/bibliography.git/plain/docs/article-89.pdf})} |
282 | that can help quantify the level of anonymity that a given mechanism | 295 | that can help quantify the level of anonymity that a given mechanism |
283 | provides, there is no such thing as complete anonymity. | 296 | provides, there is no such thing as "complete anonymity". |
284 | GNUnet's file-sharing implementation allows users to select for each | 297 | GNUnet's file-sharing implementation allows users to select for each |
285 | operation (publish, search, download) the desired level of anonymity. | 298 | operation (publish, search, download) the desired level of anonymity. |
286 | The metric used is the amount of cover traffic available to hide the | 299 | The metric used is the amount of cover traffic available to hide the |
@@ -289,10 +302,10 @@ While this metric is not as good as, for example, the theoretical metric | |||
289 | given in scientific metrics@footnote{likewise}, | 302 | given in scientific metrics@footnote{likewise}, |
290 | it is probably the best metric available to a peer with a purely local | 303 | it is probably the best metric available to a peer with a purely local |
291 | view of the world that does not rely on unreliable external information. | 304 | view of the world that does not rely on unreliable external information. |
292 | The default anonymity level is 1, which uses anonymous routing but | 305 | The default anonymity level is @code{1}, which uses anonymous routing but |
293 | imposes no minimal requirements on cover traffic. It is possible | 306 | imposes no minimal requirements on cover traffic. It is possible |
294 | to forego anonymity when this is not required. The anonymity level of 0 | 307 | to forego anonymity when this is not required. The anonymity level of |
295 | allows GNUnet to use more efficient, non-anonymous routing. | 308 | @code{0} allows GNUnet to use more efficient, non-anonymous routing. |
296 | 309 | ||
297 | @cindex How file-sharing achieves Anonymity | 310 | @cindex How file-sharing achieves Anonymity |
298 | @node How file-sharing achieves Anonymity | 311 | @node How file-sharing achieves Anonymity |
@@ -323,7 +336,7 @@ node and which ones were routed. | |||
323 | Note that in this mindset, any node can decide to break the | 336 | Note that in this mindset, any node can decide to break the |
324 | source-rewriting paradigm without violating the protocol, as this | 337 | source-rewriting paradigm without violating the protocol, as this |
325 | only reduces the amount of traffic that a node can hide its own traffic | 338 | only reduces the amount of traffic that a node can hide its own traffic |
326 | in. | 339 | in. |
327 | 340 | ||
328 | If we want to hide our actions in the traffic of other nodes, we must make | 341 | If we want to hide our actions in the traffic of other nodes, we must make |
329 | our traffic indistinguishable from the traffic that we route for others. | 342 | our traffic indistinguishable from the traffic that we route for others. |
@@ -391,6 +404,7 @@ You can find your peer identity by running @command{gnunet-peerinfo -s}. | |||
391 | 404 | ||
392 | @c FIXME: Explain or link to an explanation of the concept of public keys | 405 | @c FIXME: Explain or link to an explanation of the concept of public keys |
393 | @c and private keys. | 406 | @c and private keys. |
407 | @c FIXME: Rewrite for the latest GNS changes. | ||
394 | GNS@footnote{Matthias Wachs, Martin Schanzenbach, and Christian Grothoff. | 408 | GNS@footnote{Matthias Wachs, Martin Schanzenbach, and Christian Grothoff. |
395 | A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name | 409 | A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name |
396 | System. In proceedings of 13th International Conference on Cryptology and | 410 | System. In proceedings of 13th International Conference on Cryptology and |
@@ -399,7 +413,7 @@ Network Security (CANS 2014). 2014. | |||
399 | zones are similar to those of DNS zones, but instead of a hierarchy of | 413 | zones are similar to those of DNS zones, but instead of a hierarchy of |
400 | authorities to governing their use, GNS zones are controlled by a private | 414 | authorities to governing their use, GNS zones are controlled by a private |
401 | key. | 415 | key. |
402 | When you create a record in a DNS zone, that information stored in your | 416 | When you create a record in a DNS zone, that information is stored in your |
403 | nameserver. Anyone trying to resolve your domain then gets pointed | 417 | nameserver. Anyone trying to resolve your domain then gets pointed |
404 | (hopefully) by the centralised authority to your nameserver. | 418 | (hopefully) by the centralised authority to your nameserver. |
405 | Whereas GNS, being fully decentralized by design, stores that information | 419 | Whereas GNS, being fully decentralized by design, stores that information |
@@ -424,5 +438,5 @@ public key first. | |||
424 | @c like both are linked to public-private key pair. | 438 | @c like both are linked to public-private key pair. |
425 | Egos are your "identities" in GNUnet. Any user can assume multiple | 439 | Egos are your "identities" in GNUnet. Any user can assume multiple |
426 | identities, for example to separate their activities online. Egos can | 440 | identities, for example to separate their activities online. Egos can |
427 | correspond to pseudonyms or real-world identities. Technically, an | 441 | correspond to "pseudonyms" or "real-world identities". Technically an |
428 | ego is first of all a public-private key pair. | 442 | ego is first of all a key pair of a public- and private-key. |