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

[coderman]

On 8/29/05, Duncan B. Cragg <p2phack at cilux.org> wrote:
> ...
> Yup - sounds reasonable. What about when there is a chunk of data with
> a group or list of people who can share it - which is what I'm aiming
> for - then peer-to-peer crypto (link security) isn't enough?

there are a few ways to do this.  what you want is called a broadcast
key and part of group management is handling key distribution / pre
distribution.  in this case the key is known to the group so you are
correct that end to end isn't sufficient.


> Isn't
> data encryption needed? Then it can be passed through intermediaries
> that aren't on the list.

it will be encrypted with a current group key, so only group members
would be able to decipher it.  since we are using wireless as part of
our network the intermediary could simply be an eavesdropper :)


> All this sounds very advanced, especially compared with what I'm
> doing - so I look forward to seeing it in action! Are pet names
> group-wide or individual?

they are individual but you can inherit from the group.  if you think
of a resource collection as comprising two parts it might make better
sense.

the first part is a set of  SHA->DATA mappings.  this is what lies
within a self certifying file system, when you read the data out you
can verify that the hash is indeed what is expected.  (substitute SHA
for tiger trees, etc, depending on need - any suitable secure
identifier will work).

the second part is a signed (by quorum members) mapping of pet names
to secure ID's.  if you trust the group / quorum then inheriting their
pet names for the associated ID's is not a problem.  this does not
prevent you from making your own mapping to either override or
compliment their selection.  [in fact, sharing delta's to the common
group namespace is an important part of resource discovery but i'll
have to think about how to describe this before i just confuse us
both]

so it is still individual but using inheritance from trusted parties
to make it much less tedious to manage a large pet name space.  a
collaborative effort perhaps :)


>  Zooko would probably say they were
> individual - presumably the reason for them (avoid clashes)
> isn't an issue in one of these groups. Did you say that each
> resource has a GUID/URL (opaque to human eyes)? My own plan
> has two kinds of reference: GUID/URLs (opaque) and a DAG structure
> (like a filesystem for humans to explore).

yes, this works nicely!


> Oh - I love the phrase 'meatspace drama'!! Can I use it?  =0)

it's a highly technical term for a messy real world case :)


> Sounds like you've done what I've done: bitten off more than you
> can chew!! =0) I've been working full time on my own plans for
> eight months - and am nowhere near done.

yes; i've resigned myself to the fact that it is inevitable.  if you
look at making the entire system complete and well founded you find
yourself pulling in all sorts of hard problems like strong
identifiers, reputation and trust metrics, explicit and implicit
feedback, and then making it easy to use.

this is another reason i am big on an infrastructure view of
decentralized / peer networking services as i'd much rather reuse a
well implemented component (like a tor onion router network or an
achord DHT) that can be shared among multiple networks than build it
all (poorly) myself.  i'm crazy, but not _that_ crazy.


> Looking at the alpine archives (why did you wipe it? and also
> cubicmetercrystal?)

cubicmetercrystal is a long story; it ended up in the hands of a
domain speculator.

peertech has just recently found a temporary home and i will be
restoring content once i get it on a dedicated machine.  i should have
Verizon FiOS fiber in a few weeks (they promised this time :).

physical security for my server has become a requirement due to some
other issues that arose in previous contexts.


> and the NeuroGrid stuff, it looks like your petnames
> (and my DAG) are the key here: treat petnames as stuff that can be
> shared, then follow them around (or the peers that use them).

indeed; the attackers and cheaters can't forge self certifying
resources so the only other option is trying to game the mapping from
human descriptors to secure identifiers.  if you can make that robust
by employing reputation (the following around part, either implicit or
explicit) then you can filter out the bad mappings from the peers who
want to deceive and rely on trusted mappings from those in your peer
groups who have shown themselves reliable.