[p2p-hackers] In search of the Darknet....

[coderman]

On 8/29/05, Duncan B. Cragg <p2phack at cilux.org> wrote:
> ...
> I'm using 'privacy for small groups' to mean the ability to
> publish freely within that group (with or without that group knowing
> it was you), but (this is the difference) /not at all outside/ the
> group.

another way to think of this is distinct domains of resource
visibility for 'private groups' within a much larger shared
infrastructure.  i like this approach because so many networks have to
deal with the same issues over and over again, initial introduction to
bootstrap into the network, transitive introduction to expand your
horizon/group sizes. a sufficient pool of trusted users for decent
anonymity, etc.

sharing infrastructure in this manner (for example, an anonymizing mix
network or PIR network) can provide significant improvements over a
number of smaller, isolated subsets each providing their own.

trust becomes more difficult though, which is why the delineation
between what can and should be shared (a global GUID pseudonym), and
what is private to a group (a signed filesystem archive) needs to be
drawn carefully.


> Now, if something /were/ published in the name of the group,
> the anonymity is proportional to the size of the group when its
> members are known: perhaps an academic concept rather than a
> practical one (OK, it was me that started it, with my 'private to
> public continuum'!).
> 
> The purpose of my version of privacy is to allow social interaction
> to oil the wheels of exchange:
> 
> -: we do know each other and know our common interests.
> -: we can talk privately about them and exchange materials within our
>     group without anyone else knowing anything at all about these
>     activities.
> -: we form part of many groups in the 'global darknet'
> -: we can choose the diameter of our groups down to a file-by-file or
>     chat-by-chat basis.
> -: we can publish to a group, or to everyone (the biggest group), with
>     or without identifying ourselves.
> -: stuff can propagate out by jumping from group to group (as postulated
>     in the MS Darknet paper).

this is where the boundaries get interesting and i'm looking for
additional resources on this subject.  let me start off with a high
level view of how we broke the distinct domains of peer organization
into common types:

at the root layer you have a personal space.  this is where key
management occurs and thus it is highly protected (the loop-AES file
systems).

at the mid layer you have group spaces.  a group is simply an
arbitrary collection of peers.  all links between peers in a group are
strongly authenticated.  for example, it may consist of peers known in
your F2F social network in meatspace.  strongly authenticated means
good key distribution, so mutually signed pub keys or out of band
shared secret exchange may be necessary to establish such connections.

the last layer is the public space, and your only interaction with
public is via pseudonym or anonymously.  this is due to the lack of
strong authentication for peers discovered / communicated with in this
realm.  public is probably the easiest to understand intuitively as
anything you might publish or do anonymously or as an opaque group
would be a good candidate for shared infrastructure.

when you get to group communication you need to address the roles
peers will play in such groups.  in our architecture we selected two
distinct modes of group membership:

group member, which means resources common to the group are available
to you.  this is like read only access.

and group authority, which means you play a part in deciding the
nature of resources available to the group and the membership within
the group.

the simplest authority would be a single peer who managed a particular
group of interested member peers.  an example of this configuration
might be a newsletter with a single author.  the members would
constitute readers and the author the group authority.

for multiple authorities we selected a quorum model requiring
consensus for some or all of the group management functions.  if you
consider a software development team the quorum members or group
authorities could be the developers with commit access.  those who
utilize the committed resources in the source tree could be the group
members.  consensus may be required to merge branches or build a
release while any quorum member / group authority could commit their
own changes to a working repository.

one other aspect i will mention is that while groups support
asymmetric membership/role types they are not required to be so.  you
could have a group where every peer is a quorum member, a fully
decentralized organizational structure.

to tie this back to our model a peer group performs the following functions:
- manages peer membership within the group (this is obvious :). 
adding or removing peers requires consensus. (key management /
distribution)
- defines and distributes private resource collections.  a resource
collection in this case is a self-certifying collection of files
identified by SHA hash and the authenticated pet names applied to
these files to map them into a familiar namespace (like paths and
vfolders, etc). this may or may not require consensus.
- defines and provides public group resources to members outside of
the group (the visibility of any resource would be subject to quorum
approval, everything else is implicitly private to that group).

someone will rightly note that requiring consensus among quorum
members for certain operations will make large groups with many
authorities potentially difficult to maintain.  this is a feature! we
wanted to avoid situations where a small trusted group of peers
becomes a large untrusted group unintentionally.

if a group cannot reach consensus (peer dies, meatspace drama, etc)
then the state of the group is essentially frozen as no new directives
related to private or public group resources (and membership) may be
given.  time to create a new group among those who can agree :)

there are a lot of details missing here; documentation has taken a bit
of a back seat to experimental design as getting the usability /
intuitive interaction right is very difficult and distilling the
already too complicated design down to bare essentials is taking
longer than expected.

in short, we define three domains of interaction between peers in the
network (where 'network' is all shared infrastructure and all groups):
- personal, where the secrets that define your identity are guarded.
- group, where trusted peers act as quorum members to manage the group.
- public, where any peer or group may distribute resources
pseudonymous/anonymously.

as one last note, i often mention the live linux DVD's as our chosen
distribution mechanism.  the reason for this is that exchange of the
disc in meatspace can facilitate strong authentication between peers
in arbitrary groups as part of the initial/transitive introduction
process.  it also is a convenient source of cache space for published
group resources or other common information.

this is a fun line of conversion; please keep us advised of additional
resources you discover that are relevant to these types of
relationships in large F2F/dark networks!