diff options
author | Martin Schanzenbach <schanzen@gnunet.org> | 2024-02-24 11:38:38 +0100 |
---|---|---|
committer | Martin Schanzenbach <schanzen@gnunet.org> | 2024-02-26 13:05:34 +0100 |
commit | 2eabac0ae82fe5d92b67c8627235ca68e131a407 (patch) | |
tree | 29a02903f5708ae6daa653821132d90b73fb687d | |
parent | 900656486fbf2f9bab861aba19ca220f77313abb (diff) | |
download | gnunet-handbook-2eabac0ae82fe5d92b67c8627235ca68e131a407.tar.gz gnunet-handbook-2eabac0ae82fe5d92b67c8627235ca68e131a407.zip |
move crypto and move confidentiality
-rw-r--r-- | about.rst | 225 |
1 files changed, 112 insertions, 113 deletions
@@ -165,6 +165,118 @@ of them are also described in our research papers. First, some of the | |||
165 | concepts used in the GNUnet framework are detailed. The second part | 165 | concepts used in the GNUnet framework are detailed. The second part |
166 | describes concepts specific to anonymous file-sharing. | 166 | describes concepts specific to anonymous file-sharing. |
167 | 167 | ||
168 | Cryptography | ||
169 | ------------ | ||
170 | |||
171 | Adversaries (malicious, bad actors) outside of GNUnet are not supposed | ||
172 | to know what kind of actions a peer is involved in. Only the specific | ||
173 | neighbor of a peer that is the corresponding sender or recipient of a | ||
174 | message may know its contents, and even then application protocols may | ||
175 | place further restrictions on that knowledge. In order to ensure | ||
176 | confidentiality, GNUnet uses link encryption, that is each message | ||
177 | exchanged between two peers is encrypted using a pair of keys only known | ||
178 | to these two peers. Encrypting traffic like this makes any kind of | ||
179 | traffic analysis much harder. Naturally, for some applications, it may | ||
180 | still be desirable if even neighbors cannot determine the concrete | ||
181 | contents of a message. In GNUnet, this problem is addressed by the | ||
182 | specific application-level protocols. See for example the following | ||
183 | sections: `Anonymity <about.md#anonymity>`__, see `How file-sharing | ||
184 | achieves Anonymity <about.md#how-file-sharing-achieves-anonymity>`__, | ||
185 | and see `Deniability <about.md#deniability>`__. | ||
186 | |||
187 | Peer Identities | ||
188 | ~~~~~~~~~~~~~~~ | ||
189 | |||
190 | In GNUnet, the identity of a host is its public key called **Peer Identity**. | ||
191 | For that reason, man-in-the-middle attacks will not break the authentication or | ||
192 | accounting goals. Essentially, for GNUnet, the IP of the host has | ||
193 | nothing to do with the identity of the host. As the public key is the | ||
194 | only thing that truly matters, faking an IP, a port or any other | ||
195 | property of the underlying transport protocol is irrelevant. In fact, | ||
196 | GNUnet peers can use multiple IPs (IPv4 and IPv6) on multiple ports — or | ||
197 | even not use the IP protocol at all (by running directly on layer 2). | ||
198 | |||
199 | Peer identities are used to identify peers in the network and are unique | ||
200 | for each peer. The identity for a peer is simply its public key, which | ||
201 | is generated along with a private key when the peer is started for the | ||
202 | first time. While the identity is binary data, it is often expressed as | ||
203 | an ASCII string. For example, the following is a peer identity as you | ||
204 | might see it in various places: | ||
205 | |||
206 | :: | ||
207 | |||
208 | UAT1S6PMPITLBKSJ2DGV341JI6KF7B66AC4JVCN9811NNEGQLUN0 | ||
209 | |||
210 | You can find your peer identity by running ``gnunet-core``. | ||
211 | |||
212 | Almost all peer-to-peer communications in GNUnet are between mutually | ||
213 | authenticated peers. The authentication works by using ECDHE, that is a | ||
214 | DH (Diffie—Hellman) key exchange using ephemeral elliptic curve | ||
215 | cryptography. The ephemeral ECC (Elliptic Curve Cryptography) keys are | ||
216 | signed using **EdDSA**. The shared secret from ECDHE is used to create a | ||
217 | pair of session keys (using HKDF) which are then used to encrypt the | ||
218 | communication between the two peers using both **256-bit AES** | ||
219 | and **256-bit Twofish** (with independently derived | ||
220 | secret keys). As only the two participating hosts know the shared | ||
221 | secret, this authenticates each packet without requiring signatures each | ||
222 | time. GNUnet mostly uses the **SHA-512** hash algorithm. | ||
223 | |||
224 | GNUnet uses a special type of message to communicate a binding between | ||
225 | public (ECC) keys to their current network address. These messages are | ||
226 | commonly called **HELLOs** or peer advertisements. They contain the public | ||
227 | key of the peer and its current network addresses for various transport | ||
228 | services. A transport service is a special kind of shared library that | ||
229 | provides (possibly unreliable, out-of-order) message delivery between | ||
230 | peers. For the UDP and TCP transport services, a network address is an | ||
231 | IP and a port. GNUnet can also use other transports (HTTP, HTTPS, WLAN, | ||
232 | etc.) which use various other forms of addresses. Note that any node can | ||
233 | have many different active transport services at the same time, and each | ||
234 | of these can have a different addresses. Binding messages expire after | ||
235 | at most a week (the timeout can be shorter if the user configures the | ||
236 | node appropriately). This expiration ensures that the network will | ||
237 | eventually get rid of outdated advertisements. | ||
238 | |||
239 | For more information, refer to the following paper: | ||
240 | |||
241 | Ronaldo A. Ferreira, Christian Grothoff, and Paul Ruth. A Transport | ||
242 | Layer Abstraction for Peer-to-Peer Networks Proceedings of the 3rd | ||
243 | International Symposium on Cluster Computing and the Grid (GRID 2003), | ||
244 | 2003. (https://git.gnunet.org/bibliography.git/plain/docs/transport.pdf) | ||
245 | |||
246 | |||
247 | Egos | ||
248 | ~~~~ | ||
249 | |||
250 | **Egos** are your “identities” in GNUnet. Any user can assume multiple | ||
251 | identities, for example to separate their activities online. Egos can | ||
252 | correspond to “pseudonyms” or “real-world identities”. Technically an | ||
253 | ego is first of all a key pair of a public- and private-key. | ||
254 | The current primary use for Egos are in the GNU Name System as zone keys. | ||
255 | |||
256 | Zones in the GNU Name System | ||
257 | """""""""""""""""""""""""""" | ||
258 | |||
259 | Egos are used as **GNS zones**. | ||
260 | |||
261 | GNS zones are similar to those of DNS zones, but instead of a hierarchy | ||
262 | of authorities to governing their use, GNS zones are controlled by a | ||
263 | private key. When you create a record in a DNS zone, that information is | ||
264 | stored in your nameserver. Anyone trying to resolve your domain then | ||
265 | gets pointed (hopefully) by the centralised authority to your | ||
266 | nameserver. Whereas GNS, being fully decentralized by design, stores | ||
267 | that information in DHT. The validity of the records is assured | ||
268 | cryptographically, by signing them with the private key of the | ||
269 | respective zone. | ||
270 | |||
271 | Anyone trying to resolve records in a zone of your domain can then | ||
272 | verify the signature of the records they get from the DHT and be assured | ||
273 | that they are indeed from the respective zone. To make this work, there | ||
274 | is a 1:1 correspondence between zones and their public-private key | ||
275 | pairs. So when we talk about the owner of a GNS zone, that’s really the | ||
276 | owner of the private key. And a user accessing a zone needs to somehow | ||
277 | specify the corresponding public key first. | ||
278 | |||
279 | For more information, refer to RFC 9498. | ||
168 | 280 | ||
169 | Accounting to Encourage Resource Sharing | 281 | Accounting to Encourage Resource Sharing |
170 | ---------------------------------------- | 282 | ---------------------------------------- |
@@ -201,24 +313,6 @@ An Excess-Based Economic Model for Resource Allocation in Peer-to-Peer | |||
201 | Networks. Wirtschaftsinformatik, June 2003. | 313 | Networks. Wirtschaftsinformatik, June 2003. |
202 | (https://git.gnunet.org/bibliography.git/plain/docs/ebe.pdf) | 314 | (https://git.gnunet.org/bibliography.git/plain/docs/ebe.pdf) |
203 | 315 | ||
204 | Confidentiality | ||
205 | --------------- | ||
206 | |||
207 | Adversaries (malicious, bad actors) outside of GNUnet are not supposed | ||
208 | to know what kind of actions a peer is involved in. Only the specific | ||
209 | neighbor of a peer that is the corresponding sender or recipient of a | ||
210 | message may know its contents, and even then application protocols may | ||
211 | place further restrictions on that knowledge. In order to ensure | ||
212 | confidentiality, GNUnet uses link encryption, that is each message | ||
213 | exchanged between two peers is encrypted using a pair of keys only known | ||
214 | to these two peers. Encrypting traffic like this makes any kind of | ||
215 | traffic analysis much harder. Naturally, for some applications, it may | ||
216 | still be desirable if even neighbors cannot determine the concrete | ||
217 | contents of a message. In GNUnet, this problem is addressed by the | ||
218 | specific application-level protocols. See for example the following | ||
219 | sections: `Anonymity <about.md#anonymity>`__, see `How file-sharing | ||
220 | achieves Anonymity <about.md#how-file-sharing-achieves-anonymity>`__, | ||
221 | and see `Deniability <about.md#deniability>`__. | ||
222 | 316 | ||
223 | Anonymity | 317 | Anonymity |
224 | --------- | 318 | --------- |
@@ -337,99 +431,4 @@ Grothoff, Tzvetan Horozov, and Jussi T. Lindgren. An Encoding for | |||
337 | Censorship-Resistant Sharing. 2009. | 431 | Censorship-Resistant Sharing. 2009. |
338 | (https://git.gnunet.org/bibliography.git/plain/docs/ecrs.pdf) | 432 | (https://git.gnunet.org/bibliography.git/plain/docs/ecrs.pdf) |
339 | 433 | ||
340 | Cryptography | ||
341 | ------------ | ||
342 | |||
343 | Peer Identities | ||
344 | ~~~~~~~~~~~~~~~ | ||
345 | |||
346 | In GNUnet, the identity of a host is its public key called **Peer Identity**. | ||
347 | For that reason, man-in-the-middle attacks will not break the authentication or | ||
348 | accounting goals. Essentially, for GNUnet, the IP of the host has | ||
349 | nothing to do with the identity of the host. As the public key is the | ||
350 | only thing that truly matters, faking an IP, a port or any other | ||
351 | property of the underlying transport protocol is irrelevant. In fact, | ||
352 | GNUnet peers can use multiple IPs (IPv4 and IPv6) on multiple ports — or | ||
353 | even not use the IP protocol at all (by running directly on layer 2). | ||
354 | |||
355 | Peer identities are used to identify peers in the network and are unique | ||
356 | for each peer. The identity for a peer is simply its public key, which | ||
357 | is generated along with a private key when the peer is started for the | ||
358 | first time. While the identity is binary data, it is often expressed as | ||
359 | an ASCII string. For example, the following is a peer identity as you | ||
360 | might see it in various places: | ||
361 | |||
362 | :: | ||
363 | |||
364 | UAT1S6PMPITLBKSJ2DGV341JI6KF7B66AC4JVCN9811NNEGQLUN0 | ||
365 | |||
366 | You can find your peer identity by running ``gnunet-core``. | ||
367 | |||
368 | Almost all peer-to-peer communications in GNUnet are between mutually | ||
369 | authenticated peers. The authentication works by using ECDHE, that is a | ||
370 | DH (Diffie—Hellman) key exchange using ephemeral elliptic curve | ||
371 | cryptography. The ephemeral ECC (Elliptic Curve Cryptography) keys are | ||
372 | signed using **EdDSA**. The shared secret from ECDHE is used to create a | ||
373 | pair of session keys (using HKDF) which are then used to encrypt the | ||
374 | communication between the two peers using both **256-bit AES** | ||
375 | and **256-bit Twofish** (with independently derived | ||
376 | secret keys). As only the two participating hosts know the shared | ||
377 | secret, this authenticates each packet without requiring signatures each | ||
378 | time. GNUnet mostly uses the **SHA-512** hash algorithm. | ||
379 | |||
380 | GNUnet uses a special type of message to communicate a binding between | ||
381 | public (ECC) keys to their current network address. These messages are | ||
382 | commonly called **HELLOs** or peer advertisements. They contain the public | ||
383 | key of the peer and its current network addresses for various transport | ||
384 | services. A transport service is a special kind of shared library that | ||
385 | provides (possibly unreliable, out-of-order) message delivery between | ||
386 | peers. For the UDP and TCP transport services, a network address is an | ||
387 | IP and a port. GNUnet can also use other transports (HTTP, HTTPS, WLAN, | ||
388 | etc.) which use various other forms of addresses. Note that any node can | ||
389 | have many different active transport services at the same time, and each | ||
390 | of these can have a different addresses. Binding messages expire after | ||
391 | at most a week (the timeout can be shorter if the user configures the | ||
392 | node appropriately). This expiration ensures that the network will | ||
393 | eventually get rid of outdated advertisements. | ||
394 | |||
395 | For more information, refer to the following paper: | ||
396 | |||
397 | Ronaldo A. Ferreira, Christian Grothoff, and Paul Ruth. A Transport | ||
398 | Layer Abstraction for Peer-to-Peer Networks Proceedings of the 3rd | ||
399 | International Symposium on Cluster Computing and the Grid (GRID 2003), | ||
400 | 2003. (https://git.gnunet.org/bibliography.git/plain/docs/transport.pdf) | ||
401 | |||
402 | 434 | ||
403 | Egos | ||
404 | ~~~~ | ||
405 | |||
406 | **Egos** are your “identities” in GNUnet. Any user can assume multiple | ||
407 | identities, for example to separate their activities online. Egos can | ||
408 | correspond to “pseudonyms” or “real-world identities”. Technically an | ||
409 | ego is first of all a key pair of a public- and private-key. | ||
410 | The current primary use for Egos are in the GNU Name System as zone keys. | ||
411 | |||
412 | Zones in the GNU Name System | ||
413 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
414 | |||
415 | Egos are used as **GNS zones**. | ||
416 | |||
417 | GNS zones are similar to those of DNS zones, but instead of a hierarchy | ||
418 | of authorities to governing their use, GNS zones are controlled by a | ||
419 | private key. When you create a record in a DNS zone, that information is | ||
420 | stored in your nameserver. Anyone trying to resolve your domain then | ||
421 | gets pointed (hopefully) by the centralised authority to your | ||
422 | nameserver. Whereas GNS, being fully decentralized by design, stores | ||
423 | that information in DHT. The validity of the records is assured | ||
424 | cryptographically, by signing them with the private key of the | ||
425 | respective zone. | ||
426 | |||
427 | Anyone trying to resolve records in a zone of your domain can then | ||
428 | verify the signature of the records they get from the DHT and be assured | ||
429 | that they are indeed from the respective zone. To make this work, there | ||
430 | is a 1:1 correspondence between zones and their public-private key | ||
431 | pairs. So when we talk about the owner of a GNS zone, that’s really the | ||
432 | owner of the private key. And a user accessing a zone needs to somehow | ||
433 | specify the corresponding public key first. | ||
434 | |||
435 | For more information, refer to RFC 9498. | ||