aboutsummaryrefslogtreecommitdiff
path: root/doc/old/handbook/chapters/keyconcepts.texi
diff options
context:
space:
mode:
Diffstat (limited to 'doc/old/handbook/chapters/keyconcepts.texi')
-rw-r--r--doc/old/handbook/chapters/keyconcepts.texi350
1 files changed, 350 insertions, 0 deletions
diff --git a/doc/old/handbook/chapters/keyconcepts.texi b/doc/old/handbook/chapters/keyconcepts.texi
new file mode 100644
index 000000000..c8dd1599b
--- /dev/null
+++ b/doc/old/handbook/chapters/keyconcepts.texi
@@ -0,0 +1,350 @@
1
2@cindex Key Concepts
3@node Key Concepts
4@chapter Key Concepts
5
6In this section, the fundamental concepts of GNUnet are explained.
7@c FIXME: Use @uref{https://docs.gnunet.org/bib/, research papers}
8@c once we have the new bibliography + subdomain setup.
9Most of them are also described in our research papers.
10First, some of the concepts used in the GNUnet framework are detailed.
11The second part describes concepts specific to anonymous file-sharing.
12
13@menu
14* Authentication::
15* Accounting to Encourage Resource Sharing::
16* Confidentiality::
17* Anonymity::
18* Deniability::
19* Peer Identities::
20* Zones in the GNU Name System (GNS Zones)::
21* Egos::
22@end menu
23
24@cindex Authentication
25@node Authentication
26@section Authentication
27
28Almost all peer-to-peer communications in GNUnet are between mutually
29authenticated peers. The authentication works by using ECDHE, that is a
30DH (Diffie---Hellman) key exchange using ephemeral elliptic curve
31cryptography. The ephemeral ECC (Elliptic Curve Cryptography) keys are
32signed using ECDSA (@uref{http://en.wikipedia.org/wiki/ECDSA, ECDSA}).
33The shared secret from ECDHE is used to create a pair of session keys
34@c FIXME: Long word for HKDF. More FIXMEs: Explain MITM etc.
35(using HKDF) which are then used to encrypt the communication between the
36two peers using both 256-bit AES (Advanced Encryption Standard)
37and 256-bit Twofish (with independently derived secret keys).
38As only the two participating hosts know the shared secret, this
39authenticates each packet
40without requiring signatures each time. GNUnet uses SHA-512
41(Secure Hash Algorithm) hash codes to verify the integrity of messages.
42
43@c FIXME: A while back I got the feedback that I should try and integrate
44@c explanation boxes in the long-run. So we could explain
45@c "man-in-the-middle" and "man-in-the-middle attacks" and other words
46@c which are not common knowledge. MITM is not common knowledge. To be
47@c selfcontained, we should be able to explain words and concepts used in
48@c a chapter or paragraph without hinting at Wikipedia and other online
49@c sources which might not be available or accessible to everyone.
50@c On the other hand we could write an introductionary chapter or book
51@c that we could then reference in each chapter, which sound like it
52@c could be more reusable.
53In GNUnet, the identity of a host is its public key. For that reason,
54man-in-the-middle attacks will not break the authentication or accounting
55goals. Essentially, for GNUnet, the IP of the host has nothing to do with
56the identity of the host. As the public key is the only thing that truly
57matters, faking an IP, a port or any other property of the underlying
58transport protocol is irrelevant. In fact, GNUnet peers can use
59multiple IPs (IPv4 and IPv6) on multiple ports --- or even not use the
60IP protocol at all (by running directly on layer 2).
61@c FIXME: "IP protocol" feels wrong, but could be what people expect, as
62@c IP is "the number" and "IP protocol" the protocol itself in general
63@c knowledge?
64
65@c NOTE: For consistency we will use @code{HELLO}s throughout this Manual.
66GNUnet uses a special type of message to communicate a binding between
67public (ECC) keys to their current network address. These messages are
68commonly called @code{HELLO}s or @code{peer advertisements}.
69They contain the public key of the peer and its current network
70addresses for various transport services.
71A transport service is a special kind of shared library that
72provides (possibly unreliable, out-of-order) message delivery between
73peers.
74For the UDP and TCP transport services, a network address is an IP and a
75port.
76GNUnet can also use other transports (HTTP, HTTPS, WLAN, etc.) which use
77various other forms of addresses. Note that any node can have many
78different active transport services at the same time,
79and each of these can have a different addresses.
80Binding messages expire after at most a week (the timeout can be
81shorter if the user configures the node appropriately).
82This expiration ensures that the network will eventually get rid of
83outdated advertisements.
84
85For more information, refer to the following paper:
86
87Ronaldo A. Ferreira, Christian Grothoff, and Paul Ruth.
88A Transport Layer Abstraction for Peer-to-Peer Networks
89Proceedings of the 3rd International Symposium on Cluster Computing
90and the Grid (GRID 2003), 2003.
91(@uref{https://git.gnunet.org/bibliography.git/plain/docs/transport.pdf, https://git.gnunet.org/bibliography.git/plain/docs/transport.pdf})
92
93@cindex Accounting to Encourage Resource Sharing
94@node Accounting to Encourage Resource Sharing
95@section Accounting to Encourage Resource Sharing
96
97Most distributed P2P networks suffer from a lack of defenses or
98precautions against attacks in the form of freeloading.
99While the intentions of an attacker and a freeloader are different, their
100effect on the network is the same; they both render it useless.
101Most simple attacks on networks such as @command{Gnutella}
102involve flooding the network with traffic, particularly
103with queries that are, in the worst case, multiplied by the network.
104
105In order to ensure that freeloaders or attackers have a minimal impact
106on the network, GNUnet's file-sharing implementation (@code{FS}) tries
107to distinguish good (contributing) nodes from malicious (freeloading)
108nodes. In GNUnet, every file-sharing node keeps track of the behavior
109of every other node it has been in contact with. Many requests
110(depending on the application) are transmitted with a priority (or
111importance) level. That priority is used to establish how important
112the sender believes this request is. If a peer responds to an
113important request, the recipient will increase its trust in the
114responder: the responder contributed resources. If a peer is too busy
115to answer all requests, it needs to prioritize. For that, peers do
116not take the priorities of the requests received at face value.
117First, they check how much they trust the sender, and depending on
118that amount of trust they assign the request a (possibly lower)
119effective priority. Then, they drop the requests with the lowest
120effective priority to satisfy their resource constraints. This way,
121GNUnet's economic model ensures that nodes that are not currently
122considered to have a surplus in contributions will not be served if
123the network load is high.
124
125For more information, refer to the following paper:
126Christian Grothoff. An Excess-Based Economic Model for Resource
127Allocation in Peer-to-Peer Networks. Wirtschaftsinformatik, June 2003.
128(@uref{https://git.gnunet.org/bibliography.git/plain/docs/ebe.pdf, https://git.gnunet.org/bibliography.git/plain/docs/ebe.pdf})
129
130@cindex Confidentiality
131@node Confidentiality
132@section Confidentiality
133
134Adversaries (malicious, bad actors) outside of GNUnet are not supposed
135to know what kind of actions a peer is involved in. Only the specific
136neighbor of a peer that is the corresponding sender or recipient of a
137message may know its contents, and even then application protocols may
138place further restrictions on that knowledge. In order to ensure
139confidentiality, GNUnet uses link encryption, that is each message
140exchanged between two peers is encrypted using a pair of keys only
141known to these two peers. Encrypting traffic like this makes any kind
142of traffic analysis much harder. Naturally, for some applications, it
143may still be desirable if even neighbors cannot determine the concrete
144contents of a message. In GNUnet, this problem is addressed by the
145specific application-level protocols. See for example the following
146sections @pxref{Anonymity}, @pxref{How file-sharing achieves Anonymity},
147and @pxref{Deniability}.
148
149@cindex Anonymity
150@node Anonymity
151@section Anonymity
152
153@menu
154* How file-sharing achieves Anonymity::
155* How messaging provides Anonymity::
156@end menu
157
158Providing anonymity for users is the central goal for the anonymous
159file-sharing application. Many other design decisions follow in the
160footsteps of this requirement.
161Anonymity is never absolute. While there are various
162scientific metrics
163(Claudia Díaz, Stefaan Seys, Joris Claessens,
164and Bart Preneel. Towards measuring anonymity.
1652002.
166(@uref{https://git.gnunet.org/bibliography.git/plain/docs/article-89.pdf, https://git.gnunet.org/bibliography.git/plain/docs/article-89.pdf}))
167that can help quantify the level of anonymity that a given mechanism
168provides, there is no such thing as "complete anonymity".
169
170GNUnet's file-sharing implementation allows users to select for each
171operation (publish, search, download) the desired level of anonymity.
172The metric used is based on the amount of cover traffic needed to hide
173the request.
174
175While there is no clear way to relate the amount of available cover
176traffic to traditional scientific metrics such as the anonymity set or
177information leakage, it is probably the best metric available to a
178peer with a purely local view of the world, in that it does not rely
179on unreliable external information or a particular adversary model.
180
181The default anonymity level is @code{1}, which uses anonymous routing
182but imposes no minimal requirements on cover traffic. It is possible
183to forego anonymity when this is not required. The anonymity level of
184@code{0} allows GNUnet to use more efficient, non-anonymous routing.
185
186@cindex How file-sharing achieves Anonymity
187@node How file-sharing achieves Anonymity
188@subsection How file-sharing achieves Anonymity
189
190Contrary to other designs, we do not believe that users achieve strong
191anonymity just because their requests are obfuscated by a couple of
192indirections. This is not sufficient if the adversary uses traffic
193analysis.
194The threat model used for anonymous file sharing in GNUnet assumes that
195the adversary is quite powerful.
196In particular, we assume that the adversary can see all the traffic on
197the Internet. And while we assume that the adversary
198can not break our encryption, we assume that the adversary has many
199participating nodes in the network and that it can thus see many of the
200node-to-node interactions since it controls some of the nodes.
201
202The system tries to achieve anonymity based on the idea that users can be
203anonymous if they can hide their actions in the traffic created by other
204users.
205Hiding actions in the traffic of other users requires participating in the
206traffic, bringing back the traditional technique of using indirection and
207source rewriting. Source rewriting is required to gain anonymity since
208otherwise an adversary could tell if a message originated from a host by
209looking at the source address. If all packets look like they originate
210from one node, the adversary can not tell which ones originate from that
211node and which ones were routed.
212Note that in this mindset, any node can decide to break the
213source-rewriting paradigm without violating the protocol, as this
214only reduces the amount of traffic that a node can hide its own traffic
215in.
216
217If we want to hide our actions in the traffic of other nodes, we must make
218our traffic indistinguishable from the traffic that we route for others.
219As our queries must have us as the receiver of the reply
220(otherwise they would be useless), we must put ourselves as the receiver
221of replies that actually go to other hosts; in other words, we must
222indirect replies.
223Unlike other systems, in anonymous file-sharing as implemented on top of
224GNUnet we do not have to indirect the replies if we don't think we need
225more traffic to hide our own actions.
226
227This increases the efficiency of the network as we can indirect less under
228higher load.
229Refer to the following paper for more:
230Krista Bennett and Christian Grothoff.
231GAP --- practical anonymous networking. In Proceedings of
232Designing Privacy Enhancing Technologies, 2003.
233(@uref{https://git.gnunet.org/bibliography.git/plain/docs/aff.pdf, https://git.gnunet.org/bibliography.git/plain/docs/aff.pdf})
234
235@cindex How messaging provides Anonymity
236@node How messaging provides Anonymity
237@subsection How messaging provides Anonymity
238
239While the file-sharing tries to achieve anonymity through hiding actions in
240other traffic, the messaging service provides a weaker form of protection
241against identification.
242
243The messaging service allows the use of an anonymous ego for the signing and
244verification process of messages instead of a unique ego. This anonymous ego is
245a publicly known key pair which is shared between all peers in GNUnet.
246
247Using this ego only ensures that individual messages alone can't identify its
248sender inside of a messenger room. It should be clarified that the route of
249the traffic for each message can still be tracked to identify the senders peer
250inside of a messenger room if the threat agent controls certain peers hosting
251the room.
252
253Also opening a room in the messenger service will potentially match your peer
254identity with the internal member identity from the messenger service. So
255despite using the anonymous ego you can reveal your peer identity. This means
256to decrease the chance of being identified, it is recommended to enter rooms but
257you should not open them for others.
258
259@cindex Deniability
260@node Deniability
261@section Deniability
262
263Even if the user that downloads data and the server that provides data are
264anonymous, the intermediaries may still be targets. In particular, if the
265intermediaries can find out which queries or which content they are
266processing, a strong adversary could try to force them to censor
267certain materials.
268
269With the file-encoding used by GNUnet's anonymous file-sharing, this
270problem does not arise.
271The reason is that queries and replies are transmitted in
272an encrypted format such that intermediaries cannot tell what the query
273is for or what the content is about. Mind that this is not the same
274encryption as the link-encryption between the nodes. GNUnet has
275encryption on the network layer (link encryption, confidentiality,
276authentication) and again on the application layer (provided
277by @command{gnunet-publish}, @command{gnunet-download},
278@command{gnunet-search} and @command{gnunet-fs-gtk}).
279
280Refer to the following paper for more:
281Christian Grothoff, Krista Grothoff, Tzvetan Horozov,
282and Jussi T. Lindgren.
283An Encoding for Censorship-Resistant Sharing.
2842009.
285(@uref{https://git.gnunet.org/bibliography.git/plain/docs/ecrs.pdf, https://git.gnunet.org/bibliography.git/plain/docs/ecrs.pdf})
286
287@cindex Peer Identities
288@node Peer Identities
289@section Peer Identities
290
291Peer identities are used to identify peers in the network and are unique
292for each peer. The identity for a peer is simply its public key, which is
293generated along with a private key when the peer is started for the first
294time. While the identity is binary data, it is often expressed as an ASCII
295string. For example, the following is a peer identity as you might see it
296in various places:
297
298@example
299UAT1S6PMPITLBKSJ2DGV341JI6KF7B66AC4JVCN9811NNEGQLUN0
300@end example
301
302@noindent
303You can find your peer identity by running @command{gnunet-peerinfo -s}.
304
305@cindex Zones in the GNU Name System (GNS Zones)
306@node Zones in the GNU Name System (GNS Zones)
307@section Zones in the GNU Name System (GNS Zones)
308
309@c FIXME: Explain or link to an explanation of the concept of public keys
310@c and private keys.
311@c FIXME: Rewrite for the latest GNS changes.
312GNS zones are similar to those of DNS zones, but instead of a hierarchy of
313authorities to governing their use, GNS zones are controlled by a private
314key.
315When you create a record in a DNS zone, that information is stored in your
316nameserver. Anyone trying to resolve your domain then gets pointed
317(hopefully) by the centralised authority to your nameserver.
318Whereas GNS, being fully decentralized by design, stores that information
319in DHT. The validity of the records is assured cryptographically, by
320signing them with the private key of the respective zone.
321
322Anyone trying to resolve records in a zone of your domain can then verify
323the signature of the records they get from the DHT and be assured that
324they are indeed from the respective zone.
325To make this work, there is a 1:1 correspondence between zones and
326their public-private key pairs.
327So when we talk about the owner of a GNS zone, that's really the owner of
328the private key.
329And a user accessing a zone needs to somehow specify the corresponding
330public key first.
331
332For more information, refer to the following paper:
333
334Matthias Wachs, Martin Schanzenbach, and Christian Grothoff.
335A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name
336System. In proceedings of 13th International Conference on Cryptology and
337Network Security (CANS 2014). 2014.
338@uref{https://git.gnunet.org/bibliography.git/plain/docs/gns2014wachs.pdf, https://git.gnunet.org/bibliography.git/plain/docs/gns2014wachs.pdf}
339
340@cindex Egos
341@node Egos
342@section Egos
343
344@c what is the difference between peer identity and egos? It seems
345@c like both are linked to public-private key pair.
346Egos are your "identities" in GNUnet. Any user can assume multiple
347identities, for example to separate their activities online. Egos can
348correspond to "pseudonyms" or "real-world identities". Technically an
349ego is first of all a key pair of a public- and private-key.
350