1 files changed, 335 insertions, 0 deletions

diff --git a/doc/chapters/philosophy.texi b/doc/chapters/philosophy.texi
new file mode 100644
index 000000000..56c9bb552
--- /dev/null
+++ b/doc/chapters/philosophy.texi
@@ -0,0 +1,335 @@
+@c ***************************************************************************
+@node Philosophy
+@chapter Philosophy
+
+The foremost goal of the GNUnet project is to become a widely used,
+reliable, open, non-discriminating, egalitarian, unfettered and
+censorship-resistant system of free information exchange.
+We value free speech above state secrets, law-enforcement or
+intellectual property. GNUnet is supposed to be an anarchistic network,
+where the only limitation for peers is that they must contribute enough
+back to the network such that their resource consumption does not have
+a significant impact on other users. GNUnet should be more than just
+another file-sharing network. The plan is to offer many other services
+and in particular to serve as a development platform for the next
+generation of decentralized Internet protocols.
+
+@menu
+* Design Goals::
+* Security & Privacy::
+* Versatility::
+* Practicality::
+* Key Concepts::
+@end menu
+
+
+@c ***************************************************************************
+@node Design Goals
+@section Design Goals
+
+These are the core GNUnet design goals, in order of relative importance:
+
+@itemize
+@item GNUnet must be implemented as free software.
+@item The GNUnet must only disclose the minimal amount of information
+      necessary.
+@item The GNUnet must be decentralised and survive Byzantine failures
+      in any position in the network.
+@item The GNUnet must make it explicit to the user which entities must be
+      trustworthy when establishing secured communications.
+@item The GNUnet must use compartmentalization to protect sensitive
+      information.
+@item The GNUnet must be open and permit new peers to join.
+@item The GNUnet must be self-organizing and not depend on administrators.
+@item The GNUnet must support a diverse range of applications and devices.
+@item The GNUnet architecture must be cost effective.
+@item The GNUnet must provide incentives for peers to contribute more
+      resources than they consume.
+@end itemize
+
+
+@node Security & Privacy
+@section Security & Privacy
+
+GNUnet's primary design goals are to protect the privacy of its users and to
+guard itself against attacks or abuse. GNUnet does not have any mechanisms
+to control, track or censor users. Instead, the GNUnet protocols aim to make
+it as hard as possible to find out what is happening on the network or to
+disrupt operations. 
+
+@node Versatility
+@section Versatility
+
+We call GNUnet a peer-to-peer framework because we want to support many
+different forms of peer-to-peer applications. GNUnet uses a plugin
+architecture to make the system extensible and to encourage code reuse.
+While the first versions of the system only supported anonymous file-sharing,
+other applications are being worked on and more will hopefully follow in the
+future. A powerful synergy regarding anonymity services is created by a large
+community utilizing many diverse applications over the same software
+infrastructure. The reason is that link encryption hides the specifics
+of the traffic for non-participating observers. This way, anonymity can
+get stronger with additional (GNUnet) traffic, even if the additional
+traffic is not related to anonymous communication. Increasing anonymity is
+the primary reason why GNUnet is developed to become a peer-to-peer
+framework where many applications share the lower layers of an increasingly
+complex protocol stack. If merging traffic to hinder traffic analysis was
+not important, we could have just developed a dozen stand-alone applications
+and a few shared libraries. 
+
+@node Practicality
+@section Practicality
+
+GNUnet allows participants to trade various amounts of security in exchange
+for increased efficiency. However, it is not possible for any user's security
+and efficiency requirements to compromise the security and efficiency of
+any other user. 
+
+For GNUnet, efficiency is not paramount. If there is a more secure and still
+practical approach, we would choose to take the more secure alternative.
+@command{telnet} is more efficient than @command{ssh}, yet it is obsolete.
+Hardware gets faster, and code can be optimized. Fixing security issues as
+an afterthought is much harder. 
+
+While security is paramount, practicability is still a requirement. The most
+secure system is always the one that nobody can use. Similarly, any
+anonymous system that is extremely inefficient will only find few users.
+However, good anonymity requires a large and diverse user base. Since
+individual security requirements may vary, the only good solution here is to
+allow individuals to trade-off security and efficiency. The primary challenge
+in allowing this is to ensure that the economic incentives work properly.
+In particular, this means that it must be impossible for a user to gain
+security at the expense of other users. Many designs (e.g. anonymity via
+broadcast) fail to give users an incentive to choose a less secure but more
+efficient mode of operation. GNUnet should avoid where ever possible to
+rely on protocols that will only work if the participants are benevolent.
+While some designs have had widespread success while relying on parties
+to observe a protocol that may be sub-optimal for the individuals (e.g.
+TCP Nagle), a protocol that ensures that individual goals never conflict
+with the goals of the group is always preferable.
+
+@node Key Concepts
+@section Key Concepts
+
+In this section, the fundamental concepts of GNUnet are explained.  Most of
+them are also described in our research papers.  First, some of the concepts
+used in the GNUnet framework are detailed.  The second part describes concepts
+specific to anonymous file-sharing.
+
+@menu
+* Authentication::
+* Accounting to Encourage Resource Sharing::
+* Confidentiality::
+* Anonymity::
+* Deniability::                       
+* Peer Identities::
+* Zones in the GNU Name System (GNS Zones)::
+* Egos::
+@end menu
+
+@node Authentication
+@subsection Authentication
+
+Almost all peer-to-peer communications in GNUnet are between mutually
+authenticated peers. The authentication works by using ECDHE, that is a
+DH key exchange using ephemeral eliptic curve cryptography. The ephemeral
+ECC keys are signed using ECDSA. The shared secret from ECDHE is used to
+create a pair of session keys (using HKDF) which are then used to encrypt
+the communication between the two peers using both 256-bit AES and 256-bit
+Twofish (with independently derived secret keys). As only the two
+participating hosts know the shared secret, this authenticates each packet
+without requiring signatures each time. GNUnet uses SHA-512 hash codes to
+verify the integrity of messages. 
+
+In GNUnet, the identity of a host is its public key. For that reason,
+man-in-the-middle attacks will not break the authentication or accounting
+goals. Essentially, for GNUnet, the IP of the host has nothing to do with
+the identity of the host. As the public key is the only thing that truly
+matters, faking an IP, a port or any other property of the underlying
+transport protocol is irrelevant. In fact, GNUnet peers can use
+multiple IPs (IPv4 and IPv6) on multiple ports --- or even not use the
+IP protocol at all (by running directly on layer 2). 
+
+GNUnet uses a special type of message to communicate a binding between
+public (ECC) keys to their current network address. These messages are
+commonly called HELLOs or peer advertisements. They contain the public key
+of the peer and its current network addresses for various transport services.
+A transport service is a special kind of shared library that
+provides (possibly unreliable, out-of-order) message delivery between peers.
+For the UDP and TCP transport services, a network address is an IP and a port.
+GNUnet can also use other transports (HTTP, HTTPS, WLAN, etc.) which use
+various other forms of addresses. Note that any node can have many different
+active transport services at the same time, and each of these can have a
+different addresses. Binding messages expire after at most a week (the
+timeout can be shorter if the user configures the node appropriately). This
+expiration ensures that the network will eventually get rid of outdated
+advertisements.@
+More details can be found in this paper.
+
+@node Accounting to Encourage Resource Sharing
+@subsection Accounting to Encourage Resource Sharing
+
+Most distributed P2P networks suffer from a lack of defenses or precautions
+against attacks in the form of freeloading. While the intentions of an
+attacker and a freeloader are different, their effect on the network is the
+same; they both render it useless. Most simple attacks on networks such as
+Gnutella involve flooding the network with traffic, particularly with
+queries that are, in the worst case, multiplied by the network. 
+
+In order to ensure that freeloaders or attackers have a minimal impact on the
+network, GNUnet's file-sharing implementation tries to distinguish
+good (contributing) nodes from malicious (freeloading) nodes. In GNUnet,
+every file-sharing node keeps track of the behavior of every other node it
+has been in contact with. Many requests (depending on the application) are
+transmitted with a priority (or importance) level. That priority is used to
+establish how important the sender believes this request is. If a peer
+responds to an important request, the recipient will increase its trust in the
+responder: the responder contributed resources. If a peer is too busy to
+answer all requests, it needs to prioritize. For that, peers to not take the
+priorities of the requests received at face value. First, they check how much
+they trust the sender, and depending on that amount of trust they assign the
+request a (possibly lower) effective priority. Then, they drop the requests
+with the lowest effective priority to satisfy their resource constraints. This
+way, GNUnet's economic model ensures that nodes that are not currently
+considered to have a surplus in contributions will not be served if the
+network load is high. More details can be found in this paper.
+
+@node Confidentiality
+@subsection Confidentiality
+
+Adversaries outside of GNUnet are not supposed to know what kind of actions a
+peer is involved in. Only the specific neighbor of a peer that is the
+corresponding sender or recipient of a message may know its contents, and even
+then application protocols may place further restrictions on that knowledge.
+In order to ensure confidentiality, GNUnet uses link encryption, that is each
+message exchanged between two peers is encrypted using a pair of keys only
+known to these two peers. Encrypting traffic like this makes any kind of
+traffic analysis much harder. Naturally, for some applications, it may still
+be desirable if even neighbors cannot determine the concrete contents of a
+message. In GNUnet, this problem is addressed by the specific
+application-level protocols (see for example, deniability and anonymity in
+anonymous file sharing).
+
+@node Anonymity
+@subsection Anonymity
+
+Providing anonymity for users is the central goal for the anonymous
+file-sharing application. Many other design decisions follow in the footsteps
+of this requirement. Anonymity is never absolute. While there are various
+scientific metrics that can help quantify the level of anonymity that a
+given mechanism provides, there is no such thing as complete anonymity.
+GNUnet's file-sharing implementation allows users to select for each
+operation (publish, search, download) the desired level of anonymity.
+The metric used is the amount of cover traffic available to hide the request.
+While this metric is not as good as, for example, the theoretical metric
+given in scientific metrics, it is probably the best metric available to
+a peer with a purely local view of the world that does not rely on unreliable
+external information. The default anonymity level is 1, which uses anonymous
+routing but imposes no minimal requirements on cover traffic. It is possible
+to forego anonymity when this is not required. The anonymity level of 0
+allows GNUnet to use more efficient, non-anonymous routing.
+
+@menu
+* How file-sharing achieves Anonymity:
+@end menu
+
+@node How file-sharing achieves Anonymity
+@subsubsection How file-sharing achieves Anonymity
+
+Contrary to other designs, we do not believe that users achieve strong
+anonymity just because their requests are obfuscated by a couple of
+indirections. This is not sufficient if the adversary uses traffic analysis.
+The threat model used for anonymous file sharing in GNUnet assumes that the
+adversary is quite powerful. In particular, we assume that the adversary can
+see all the traffic on the Internet. And while we assume that the adversary
+can not break our encryption, we assume that the adversary has many
+participating nodes in the network and that it can thus see many of the
+node-to-node interactions since it controls some of the nodes. 
+
+The system tries to achieve anonymity based on the idea that users can be
+anonymous if they can hide their actions in the traffic created by other users.
+Hiding actions in the traffic of other users requires participating in the
+traffic, bringing back the traditional technique of using indirection and
+source rewriting. Source rewriting is required to gain anonymity since
+otherwise an adversary could tell if a message originated from a host by
+looking at the source address. If all packets look like they originate from
+a node, the adversary can not tell which ones originate from that node and
+which ones were routed. Note that in this mindset, any node can decide to
+break the source-rewriting paradigm without violating the protocol, as this
+only reduces the amount of traffic that a node can hide its own traffic in. 
+
+If we want to hide our actions in the traffic of other nodes, we must make
+our traffic indistinguishable from the traffic that we route for others. As
+our queries must have us as the receiver of the reply (otherwise they would
+be useless), we must put ourselves as the receiver of replies that actually
+go to other hosts; in other words, we must indirect replies. Unlike other
+systems, in anonymous file-sharing as implemented on top of GNUnet we do not
+have to indirect the replies if we don't think we need more traffic to hide
+our own actions.@
+
+This increases the efficiency of the network as we can indirect less under
+higher load. More details can be found in this paper. 
+
+@node Deniability
+@subsection Deniability
+
+Even if the user that downloads data and the server that provides data are
+anonymous, the intermediaries may still be targets. In particular, if the
+intermediaries can find out which queries or which content they are
+processing, a strong adversary could try to force them to censor
+certain materials. 
+
+With the file-encoding used by GNUnet's anonymous file-sharing, this problem
+does not arise.  The reason is that queries and replies are transmitted in
+an encrypted format such that intermediaries cannot tell what the query
+is for or what the content is about.  Mind that this is not the same
+encryption as the link-encryption between the nodes.  GNUnet has
+encryption on the network layer (link encryption, confidentiality,
+authentication) and again on the application layer (provided
+by @command{gnunet-publish}, @command{gnunet-download}, @command{gnunet-search}
+and @command{gnunet-gtk}).  More details can be found here.
+
+@node Peer Identities
+@subsection Peer Identities
+
+Peer identities are used to identify peers in the network and are unique for
+each peer.  The identity for a peer is simply its public key, which is
+generated along with a private key the peer is started for the first time.
+While the identity is binary data, it is often expressed as ASCII string.
+For example, the following is a peer identity as you might see it in
+various places:@
+@code{@
+ UAT1S6PMPITLBKSJ2DGV341JI6KF7B66AC4JVCN9811NNEGQLUN0@
+}
+
+You can find your peer identity by running@
+@command{gnunet-peerinfo -s}
+
+@node Zones in the GNU Name System (GNS Zones)
+@subsection Zones in the GNU Name System (GNS Zones)
+
+GNS zones are similar to those of DNS zones, but instead of a hierarchy of
+authorities to governing their use, GNS zones are controlled by a private key.
+When you create a record in a DNS zone, that information stored in your
+nameserver.  Anyone trying to resolve your domain then gets pointed (hopefully)
+by the centralised authority to your nameserver.  Whereas GNS, being
+decentralised by design, stores that information in DHT.  The validity of the
+records is assured cryptographically, by signing them with the private key of
+the respective zone.
+
+Anyone trying to resolve records in a zone your domain can then verify the
+signature on the records they get from the DHT and be assured that they are
+indeed from the respective zone.  To make this work, there is a 1:1
+correspondence between zones and their public-private key pairs.  So when we
+talk about the owner of a GNS zone, that's really the owner of the private
+key.  And a user accessing a zone needs to somehow specify the corresponding
+public key first.
+
+@node Egos
+@subsection Egos
+
+Egos are your "identities" in GNUnet.  Any user can assume multiple
+identities, for example to separate his activities online.  Egos can
+correspond to pseudonyms or real-world identities.  Technically, an
+ego is first of all a public-private key pair.
+