diff options
author | ng0 <ng0@infotropique.org> | 2017-10-28 18:41:01 +0000 |
---|---|---|
committer | ng0 <ng0@infotropique.org> | 2017-10-28 18:41:01 +0000 |
commit | 3df09f73a2a93b9858ac6029e1583829c07f2cf1 (patch) | |
tree | 9e391643918dcb75bf7b109032f32fa70eb9b6bb /doc | |
parent | db1c7a0dd711d032bf874f6f6bf13e80aa2a07d1 (diff) | |
download | gnunet-3df09f73a2a93b9858ac6029e1583829c07f2cf1.tar.gz gnunet-3df09f73a2a93b9858ac6029e1583829c07f2cf1.zip |
+
Diffstat (limited to 'doc')
-rw-r--r-- | doc/documentation/chapters/philosophy.texi | 90 |
1 files changed, 46 insertions, 44 deletions
diff --git a/doc/documentation/chapters/philosophy.texi b/doc/documentation/chapters/philosophy.texi index 0f948fcab..ac9b91c80 100644 --- a/doc/documentation/chapters/philosophy.texi +++ b/doc/documentation/chapters/philosophy.texi | |||
@@ -1,4 +1,4 @@ | |||
1 | @cindex Philosopy | 1 | @cindex Philosophy |
2 | @node Philosophy | 2 | @node Philosophy |
3 | @chapter Philosophy | 3 | @chapter Philosophy |
4 | 4 | ||
@@ -65,18 +65,18 @@ find out what is happening on the network or to disrupt operations. | |||
65 | @section Versatility | 65 | @section Versatility |
66 | 66 | ||
67 | We call GNUnet a peer-to-peer framework because we want to support many | 67 | We call GNUnet a peer-to-peer framework because we want to support many |
68 | different forms of peer-to-peer applications. GNUnet uses a plugin | 68 | different forms of peer-to-peer applications. GNUnet uses a plugin |
69 | architecture to make the system extensible and to encourage code reuse. | 69 | architecture to make the system extensible and to encourage code reuse. |
70 | While the first versions of the system only supported anonymous | 70 | While the first versions of the system only supported anonymous |
71 | file-sharing, other applications are being worked on and more will | 71 | file-sharing, other applications are being worked on and more will |
72 | hopefully follow in the future. | 72 | hopefully follow in the future. |
73 | A powerful synergy regarding anonymity services is created by a large | 73 | A powerful synergy regarding anonymity services is created by a large |
74 | community utilizing many diverse applications over the same software | 74 | community utilizing many diverse applications over the same software |
75 | infrastructure. The reason is that link encryption hides the specifics | 75 | infrastructure. The reason is that link encryption hides the specifics |
76 | of the traffic for non-participating observers. This way, anonymity can | 76 | of the traffic for non-participating observers. This way, anonymity can |
77 | get stronger with additional (GNUnet) traffic, even if the additional | 77 | get stronger with additional (GNUnet) traffic, even if the additional |
78 | traffic is not related to anonymous communication. Increasing anonymity is | 78 | traffic is not related to anonymous communication. Increasing anonymity |
79 | the primary reason why GNUnet is developed to become a peer-to-peer | 79 | is the primary reason why GNUnet is developed to become a peer-to-peer |
80 | framework where many applications share the lower layers of an | 80 | framework where many applications share the lower layers of an |
81 | increasingly complex protocol stack. | 81 | increasingly complex protocol stack. |
82 | If merging traffic to hinder traffic analysis was not important, | 82 | If merging traffic to hinder traffic analysis was not important, |
@@ -88,22 +88,22 @@ and a few shared libraries. | |||
88 | @section Practicality | 88 | @section Practicality |
89 | 89 | ||
90 | GNUnet allows participants to trade various amounts of security in | 90 | GNUnet allows participants to trade various amounts of security in |
91 | exchange for increased efficiency. However, it is not possible for any | 91 | exchange for increased efficiency. However, it is not possible for any |
92 | user's security and efficiency requirements to compromise the security | 92 | user's security and efficiency requirements to compromise the security |
93 | and efficiency of any other user. | 93 | and efficiency of any other user. |
94 | 94 | ||
95 | For GNUnet, efficiency is not paramount. If there is a more secure and | 95 | For GNUnet, efficiency is not paramount. If there is a more secure and |
96 | still practical approach, we would choose to take the more secure | 96 | still practical approach, we would choose to take the more secure |
97 | alternative. @command{telnet} is more efficient than @command{ssh}, yet | 97 | alternative. @command{telnet} is more efficient than @command{ssh}, yet |
98 | it is obsolete. | 98 | it is obsolete. |
99 | Hardware gets faster, and code can be optimized. Fixing security issues as | 99 | Hardware gets faster, and code can be optimized. Fixing security issues |
100 | an afterthought is much harder. | 100 | as an afterthought is much harder. |
101 | 101 | ||
102 | While security is paramount, practicability is still a requirement. | 102 | While security is paramount, practicability is still a requirement. |
103 | The most secure system is always the one that nobody can use. | 103 | The most secure system is always the one that nobody can use. |
104 | Similarly, any anonymous system that is extremely inefficient will only | 104 | Similarly, any anonymous system that is extremely inefficient will only |
105 | find few users. | 105 | find few users. |
106 | However, good anonymity requires a large and diverse user base. Since | 106 | However, good anonymity requires a large and diverse user base. Since |
107 | individual security requirements may vary, the only good solution here is | 107 | individual security requirements may vary, the only good solution here is |
108 | to allow individuals to trade-off security and efficiency. | 108 | to allow individuals to trade-off security and efficiency. |
109 | The primary challenge in allowing this is to ensure that the economic | 109 | The primary challenge in allowing this is to ensure that the economic |
@@ -144,28 +144,28 @@ The second part describes concepts specific to anonymous file-sharing. | |||
144 | @subsection Authentication | 144 | @subsection Authentication |
145 | 145 | ||
146 | Almost all peer-to-peer communications in GNUnet are between mutually | 146 | Almost all peer-to-peer communications in GNUnet are between mutually |
147 | authenticated peers. The authentication works by using ECDHE, that is a | 147 | authenticated peers. The authentication works by using ECDHE, that is a |
148 | DH key exchange using ephemeral eliptic curve cryptography. The ephemeral | 148 | DH key exchange using ephemeral eliptic curve cryptography. The ephemeral |
149 | ECC keys are signed using ECDSA. The shared secret from ECDHE is used to | 149 | ECC keys are signed using ECDSA. The shared secret from ECDHE is used to |
150 | create a pair of session keys (using HKDF) which are then used to encrypt | 150 | create a pair of session keys (using HKDF) which are then used to encrypt |
151 | the communication between the two peers using both 256-bit AES and 256-bit | 151 | the communication between the two peers using both 256-bit AES and 256-bit |
152 | Twofish (with independently derived secret keys). As only the two | 152 | Twofish (with independently derived secret keys). As only the two |
153 | participating hosts know the shared secret, this authenticates each packet | 153 | participating hosts know the shared secret, this authenticates each packet |
154 | without requiring signatures each time. GNUnet uses SHA-512 hash codes to | 154 | without requiring signatures each time. GNUnet uses SHA-512 hash codes to |
155 | verify the integrity of messages. | 155 | verify the integrity of messages. |
156 | 156 | ||
157 | In GNUnet, the identity of a host is its public key. For that reason, | 157 | In GNUnet, the identity of a host is its public key. For that reason, |
158 | man-in-the-middle attacks will not break the authentication or accounting | 158 | man-in-the-middle attacks will not break the authentication or accounting |
159 | goals. Essentially, for GNUnet, the IP of the host has nothing to do with | 159 | goals. Essentially, for GNUnet, the IP of the host has nothing to do with |
160 | the identity of the host. As the public key is the only thing that truly | 160 | the identity of the host. As the public key is the only thing that truly |
161 | matters, faking an IP, a port or any other property of the underlying | 161 | matters, faking an IP, a port or any other property of the underlying |
162 | transport protocol is irrelevant. In fact, GNUnet peers can use | 162 | transport protocol is irrelevant. In fact, GNUnet peers can use |
163 | multiple IPs (IPv4 and IPv6) on multiple ports --- or even not use the | 163 | multiple IPs (IPv4 and IPv6) on multiple ports --- or even not use the |
164 | IP protocol at all (by running directly on layer 2). | 164 | IP protocol at all (by running directly on layer 2). |
165 | 165 | ||
166 | @c NOTE: For consistency we will use @code{HELLO}s throughout this Manual. | 166 | @c NOTE: For consistency we will use @code{HELLO}s throughout this Manual. |
167 | GNUnet uses a special type of message to communicate a binding between | 167 | GNUnet uses a special type of message to communicate a binding between |
168 | public (ECC) keys to their current network address. These messages are | 168 | public (ECC) keys to their current network address. These messages are |
169 | commonly called @code{HELLO}s or peer advertisements. | 169 | commonly called @code{HELLO}s or peer advertisements. |
170 | They contain the public key of the peer and its current network | 170 | They contain the public key of the peer and its current network |
171 | addresses for various transport services. | 171 | addresses for various transport services. |
@@ -175,7 +175,7 @@ peers. | |||
175 | For the UDP and TCP transport services, a network address is an IP and a | 175 | For the UDP and TCP transport services, a network address is an IP and a |
176 | port. | 176 | port. |
177 | GNUnet can also use other transports (HTTP, HTTPS, WLAN, etc.) which use | 177 | GNUnet can also use other transports (HTTP, HTTPS, WLAN, etc.) which use |
178 | various other forms of addresses. Note that any node can have many | 178 | various other forms of addresses. Note that any node can have many |
179 | different active transport services at the same time, | 179 | different active transport services at the same time, |
180 | and each of these can have a different addresses. | 180 | and each of these can have a different addresses. |
181 | Binding messages expire after at most a week (the timeout can be | 181 | Binding messages expire after at most a week (the timeout can be |
@@ -202,19 +202,21 @@ with queries that are, in the worst case, multiplied by the network. | |||
202 | 202 | ||
203 | In order to ensure that freeloaders or attackers have a minimal impact on | 203 | In order to ensure that freeloaders or attackers have a minimal impact on |
204 | the network, GNUnet's file-sharing implementation tries to distinguish | 204 | the network, GNUnet's file-sharing implementation tries to distinguish |
205 | good (contributing) nodes from malicious (freeloading) nodes. In GNUnet, | 205 | good (contributing) nodes from malicious (freeloading) nodes. In GNUnet, |
206 | every file-sharing node keeps track of the behavior of every other node it | 206 | every file-sharing node keeps track of the behavior of every other node it |
207 | has been in contact with. Many requests (depending on the application) are | 207 | has been in contact with. Many requests (depending on the application) |
208 | transmitted with a priority (or importance) level. That priority is used | 208 | are transmitted with a priority (or importance) level. |
209 | to establish how important the sender believes this request is. If a peer | 209 | That priority is used to establish how important the sender believes |
210 | responds to an important request, the recipient will increase its trust in | 210 | this request is. If a peer responds to an important request, the |
211 | the responder: the responder contributed resources. If a peer is too busy | 211 | recipient will increase its trust in the responder: |
212 | to answer all requests, it needs to prioritize. For that, peers to not | 212 | the responder contributed resources. |
213 | take the priorities of the requests received at face value. | 213 | If a peer is too busy to answer all requests, it needs to prioritize. |
214 | For that, peers to not take the priorities of the requests received at | ||
215 | face value. | ||
214 | First, they check how much they trust the sender, and depending on that | 216 | First, they check how much they trust the sender, and depending on that |
215 | amount of trust they assign the request a (possibly lower) effective | 217 | amount of trust they assign the request a (possibly lower) effective |
216 | priority. Then, they drop the requests with the lowest effective priority | 218 | priority. Then, they drop the requests with the lowest effective priority |
217 | to satisfy their resource constraints. This way, GNUnet's economic model | 219 | to satisfy their resource constraints. This way, GNUnet's economic model |
218 | ensures that nodes that are not currently considered to have a surplus in | 220 | ensures that nodes that are not currently considered to have a surplus in |
219 | contributions will not be served if the network load is high. | 221 | contributions will not be served if the network load is high. |
220 | @footnote{Christian Grothoff. An Excess-Based Economic Model for Resource | 222 | @footnote{Christian Grothoff. An Excess-Based Economic Model for Resource |
@@ -227,7 +229,7 @@ Allocation in Peer-to-Peer Networks. Wirtschaftsinformatik, June 2003. | |||
227 | @subsection Confidentiality | 229 | @subsection Confidentiality |
228 | 230 | ||
229 | Adversaries outside of GNUnet are not supposed to know what kind of | 231 | Adversaries outside of GNUnet are not supposed to know what kind of |
230 | actions a peer is involved in. Only the specific neighbor of a peer that | 232 | actions a peer is involved in. Only the specific neighbor of a peer that |
231 | is the corresponding sender or recipient of a message may know its | 233 | is the corresponding sender or recipient of a message may know its |
232 | contents, and even then application protocols may place further | 234 | contents, and even then application protocols may place further |
233 | restrictions on that knowledge. | 235 | restrictions on that knowledge. |
@@ -235,7 +237,7 @@ In order to ensure confidentiality, GNUnet uses link encryption, that is | |||
235 | each message exchanged between two peers is encrypted using a pair of | 237 | each message exchanged between two peers is encrypted using a pair of |
236 | keys only known to these two peers. | 238 | keys only known to these two peers. |
237 | Encrypting traffic like this makes any kind of traffic analysis much | 239 | Encrypting traffic like this makes any kind of traffic analysis much |
238 | harder. Naturally, for some applications, it may still be desirable if | 240 | harder. Naturally, for some applications, it may still be desirable if |
239 | even neighbors cannot determine the concrete contents of a message. | 241 | even neighbors cannot determine the concrete contents of a message. |
240 | In GNUnet, this problem is addressed by the specific application-level | 242 | In GNUnet, this problem is addressed by the specific application-level |
241 | protocols (see for example, deniability and anonymity in anonymous file | 243 | protocols (see for example, deniability and anonymity in anonymous file |
@@ -250,9 +252,9 @@ sharing). | |||
250 | @end menu | 252 | @end menu |
251 | 253 | ||
252 | Providing anonymity for users is the central goal for the anonymous | 254 | Providing anonymity for users is the central goal for the anonymous |
253 | file-sharing application. Many other design decisions follow in the | 255 | file-sharing application. Many other design decisions follow in the |
254 | footsteps of this requirement. | 256 | footsteps of this requirement. |
255 | Anonymity is never absolute. While there are various | 257 | Anonymity is never absolute. While there are various |
256 | scientific metrics@footnote{Claudia Dı́az, Stefaan Seys, Joris Claessens, | 258 | scientific metrics@footnote{Claudia Dı́az, Stefaan Seys, Joris Claessens, |
257 | and Bart Preneel. Towards measuring anonymity. | 259 | and Bart Preneel. Towards measuring anonymity. |
258 | 2002. | 260 | 2002. |
@@ -268,7 +270,7 @@ given in scientific metrics@footnote{likewise}, | |||
268 | it is probably the best metric available to a peer with a purely local | 270 | it is probably the best metric available to a peer with a purely local |
269 | view of the world that does not rely on unreliable external information. | 271 | view of the world that does not rely on unreliable external information. |
270 | The default anonymity level is 1, which uses anonymous routing but | 272 | The default anonymity level is 1, which uses anonymous routing but |
271 | imposes no minimal requirements on cover traffic. It is possible | 273 | imposes no minimal requirements on cover traffic. It is possible |
272 | to forego anonymity when this is not required. The anonymity level of 0 | 274 | to forego anonymity when this is not required. The anonymity level of 0 |
273 | allows GNUnet to use more efficient, non-anonymous routing. | 275 | allows GNUnet to use more efficient, non-anonymous routing. |
274 | 276 | ||
@@ -278,12 +280,12 @@ allows GNUnet to use more efficient, non-anonymous routing. | |||
278 | 280 | ||
279 | Contrary to other designs, we do not believe that users achieve strong | 281 | Contrary to other designs, we do not believe that users achieve strong |
280 | anonymity just because their requests are obfuscated by a couple of | 282 | anonymity just because their requests are obfuscated by a couple of |
281 | indirections. This is not sufficient if the adversary uses traffic | 283 | indirections. This is not sufficient if the adversary uses traffic |
282 | analysis. | 284 | analysis. |
283 | The threat model used for anonymous file sharing in GNUnet assumes that | 285 | The threat model used for anonymous file sharing in GNUnet assumes that |
284 | the adversary is quite powerful. | 286 | the adversary is quite powerful. |
285 | In particular, we assume that the adversary can see all the traffic on | 287 | In particular, we assume that the adversary can see all the traffic on |
286 | the Internet. And while we assume that the adversary | 288 | the Internet. And while we assume that the adversary |
287 | can not break our encryption, we assume that the adversary has many | 289 | can not break our encryption, we assume that the adversary has many |
288 | participating nodes in the network and that it can thus see many of the | 290 | participating nodes in the network and that it can thus see many of the |
289 | node-to-node interactions since it controls some of the nodes. | 291 | node-to-node interactions since it controls some of the nodes. |
@@ -293,9 +295,9 @@ anonymous if they can hide their actions in the traffic created by other | |||
293 | users. | 295 | users. |
294 | Hiding actions in the traffic of other users requires participating in the | 296 | Hiding actions in the traffic of other users requires participating in the |
295 | traffic, bringing back the traditional technique of using indirection and | 297 | traffic, bringing back the traditional technique of using indirection and |
296 | source rewriting. Source rewriting is required to gain anonymity since | 298 | source rewriting. Source rewriting is required to gain anonymity since |
297 | otherwise an adversary could tell if a message originated from a host by | 299 | otherwise an adversary could tell if a message originated from a host by |
298 | looking at the source address. If all packets look like they originate | 300 | looking at the source address. If all packets look like they originate |
299 | from a node, the adversary can not tell which ones originate from that | 301 | from a node, the adversary can not tell which ones originate from that |
300 | node and which ones were routed. | 302 | node and which ones were routed. |
301 | Note that in this mindset, any node can decide to break the | 303 | Note that in this mindset, any node can decide to break the |
@@ -324,7 +326,7 @@ Designing Privacy Enhancing Technologies, 2003. | |||
324 | @subsection Deniability | 326 | @subsection Deniability |
325 | 327 | ||
326 | Even if the user that downloads data and the server that provides data are | 328 | Even if the user that downloads data and the server that provides data are |
327 | anonymous, the intermediaries may still be targets. In particular, if the | 329 | anonymous, the intermediaries may still be targets. In particular, if the |
328 | intermediaries can find out which queries or which content they are | 330 | intermediaries can find out which queries or which content they are |
329 | processing, a strong adversary could try to force them to censor | 331 | processing, a strong adversary could try to force them to censor |
330 | certain materials. | 332 | certain materials. |