Re: [Help-gnunet] Questions about GNUnet

[Christian Grothoff]

Hi Philipp,

Some answers inline below.

On 04/18/2017 09:18 AM, Philipp wrote:
> Hello everyone,
> I am currently working on my master's thesis at the University of Ulm.
> As a part of my thesis, I performed a literature survey on some systems
> that offer anonymity properties in P2P environments, among them GNUnet.
> 
> I have a few questions regarding GNUnet. I hope it is fine to post them
> here on the mailing list. Unfortunately, when visiting the FAQ website
> https://gnunet.org/faq-page I just get an emtpy page, so I couldn't
> figure out whether there are already answers posted to some of the
> questions I have.
> 
> I would be very grateful for help on some of these topics.
> 
> 1) In [1], it is mentioned that nodes observe the behavior of
> neighboring nodes. It also states that a node might pass files (or
> possbily blocks of a file) to other nodes depending on how trustworthy
> they seem. Are these trust values derived based on the scheme described
> in [2]?

Nodes will pass blocks of files (never files) based on available
bandwidth (trying to keep their traffic profile constant).  However, IF
a peer has earned trust ([2]) and IF that peer made a prioritized
request, nodes will prioritize such requests (possibly doing less work
for others, dropping other peer's blocks) over other requests from nodes
that either did not earn trust OR did not make a prioritized request.
Trust is lost/reduced/reassigned when making prioritized requests.

> 2) As far as I understood, files that I want to publish are always
> placed on my local node and not actively distributed into the network. 

The files will be actively distributed into the network IF your
configuration allows it (CONTENT_PUSHING = YES).

> I can, however, decide whether I want to generate a copy and place it in
> my local store in encrypted form or whether I just want to create the
> index and blocks are encrypted "on-the-fly" when requested.

That's an orthogonal concept; indexing vs. insertion is about how
locally-published files are stored (kept in clear in FS or encrypted in
DB).  This has no impact on the pushing strategy (see above).

> In [3], the
> term "content migration" is used. Are blocks actively pushed to other
> nodes even without requests on them?

Yes, see CONTENT_PUSHING and CONTENT_CACHING options.

> 3) https://gnunet.org/file-sharing-concepts mentions a replication level
> for blocks. What exactly is the purpose for this and how does it affect
> replication?

If you enable CONTENT_PUSHING, the peer will prioritize making
replication-level PUSH operations of each block of your file before
going back to making "random" pushes.  Basically, it's a way to give new
blocks a 'push' in terms of visibility.

> 4) In the GAP approach described in [4], a peer, say A, can decide to
> skip the source rewriting step. On the return path, the successor of A
> needs to communicate directly with the predecessor of A. However, GNUnet
> uses encrypted links. Does this imply that these nodes need to perform a
> session key exchange before being able to send the result along the
> return path?

Yes.

> 5) Taking a look at [3] or [4], the network is described as a rather
> unstructured P2P network. I know also about the DHT based R5N [5] which
> is a structured approach. How does these two play together in terms of
> network management? Are there separate routing tables and maintenance
> protocols?

Yes, the DHT's routing table is separate from (anonymous) FS, and the
DHT uses R5N's topology maintenance while FS uses 'topology' (F2F,
gossip, etc.).  However, these do interact some, as core-level encrypted
connections found by one may be used immediately by the other and vice
versa.

> 6) I know R5N is currently used for non-anonymous file sharing.

Indirectly via CADET, yes.

> There is
> not really sender anonymity due to the hop counter that is used to
> determine when to switch from random to deterministic routing.

Nope, it's worse as CADET explicitly identifies the end-points and
creates a multi-hope end-to-end encrypted communication channel.

> Furthermore, packets are not intentionally delayed to impede traffic
> analysis. However, would it be possible to apply similar mechanisms just
> like in GAP and, e.g., replace the hop counter or use probabilistic
> behavir to achieve sender anonymity in R5N?

The likelihood that a particular peer issues queries for a particular
key in a DHT is quite skewed; it'll be tricky to get this "right" for a
DHT, and I do not think your simple method works sufficiently well for
the DHT. For FS: see my comment on CADET.

> 7) Does GNUnet use erasure codes to tolerate the loss of some of the
> blocks of a file? Or is a file unretrievable if a block is lost?

We (still) do not use ECC.

> 8) Are there any performance measurements in a scientific publication
> about GAP or GNUnets anonymous file sharing in general?

AFAIK no.  Initially our performance was always limited by database IO
(even for the largest setups we could manage), and for testbed-style
setups this would likely still be a problem today.  Also, several people
said they would script some kind of "realistic behavior" for users (who
publishes/searches/downloads what), but AFAIK nobody ever actually
proposed (not to mention implemented) a good benchmark.

> [1] Grothoff, Christian, et al. "The gnet whitepaper." Purdue University
> (2002).
> [2] Grothoff, Christian. "Resource allocation in peer-to-peer networks:
> An excess-based economic model." Wirtschaftsinformatik 45.3 (2003):
> 285-292.
> [3] Bennett, Krista, et al. "Gnunet-a truly anonymous networking
> infrastructure." In: Proc. Privacy Enhancing Technologies Workshop (PET.
> 2002.
> [4] Bennett, Krista, and Christian Grothoff. "GAP–practical anonymous
> networking." International Workshop on Privacy Enhancing Technologies.
> Springer Berlin Heidelberg, 2003.
> [5] Evans, Nathan S., and Christian Grothoff. "R5n: Randomized recursive
> routing for restricted-route networks." Network and System Security
> (NSS), 2011 5th International Conference on. IEEE, 2011.
> 
> Best regards,

Happy hacking!

Christian

signature.asc
Description: OpenPGP digital signature