[Blocks-development] Avoiding malicious content-dilution through PKI encryption

[Michael S. Jr. <bl...@ms...>]

I posted this to the GnutellaNG working group message board a while back,
and the idea wasn't met very well.  It seems this idea isn't really in line
with the Gnutella project's goals.

Since this project is rather new, maybe we'd like to implement this in
Blocks.


-----Begin snipped post from GnutellaNG message board-----

I originally posted this message on the GnutellaDev message board. It seems
to fit in better with the existing content at GnutellaNG.

I'm repeating a lot of information you guys already know, so please forgive
the discussion of public-key cryptography and web-of-trust systems.

Also posted this to slashdot on a thread about jamming Napster with
mislabeled content. It got moderated up to 2, so it probably didn't even get
read. :(

I believe what's needed is a distributed content- and host-verification
system based on public-key cryptography signatures and a web-of-trust. (GPG
sources could be used for the PK crypto) I don't really have a good response
for the privacy concerns about plastering persistent identities all over the
content out there...but that's just one of many things that need to be
discussed.

For those unfamiliar with the distributed web-of-trust implemented in the
original PGP release: the idea is that using public-key crypto (where the
encryption key has two halves, a public- and a private- half, which are
linked in a very special mathematical way...what you 'do' with one half
requires the other half to 'undo') you can place signatures on things --
include a hash of the content, create a message using your private key which
can be verified by your public key.

In the PGP world this is used to create a web-of-trust: if you have a key
owned by a person you trust (say, your very technical neighbor John) you
might trust two things about his key: you might or might not trust that his
key will remained owned by him (trusting the identity of the key) and you
might or might not trust the integrity of the owner in certifying other keys
(trusting the integrity of signatures made by the key). So you could trust
the key of a complete sociopath, merely saying that you know the key belongs
to him personally...but you don't exactly trust his signatures on other
peoples' keys. Or you could trust both the key and the signatures of your
neighbor John -- not only do you believe his key belongs to him personally,
but you believe that when he puts a signature on some third-party key out
there, then that third-party key probably really belongs to that person.

In Gnutella, this could be used to maintain a distributed database of
trusted individuals and servers (anonymity will be discussed later) and
trusted content. The effect will be that, for a given user, once he's taken
the time to tell Gnutella how accurate the songs he downloads are...these
songs weren't what their filename claimed they were, while these other songs
were accurate and of X quality...he can publish signatures affirming to
other users that files with X length and Y CRC really do contain Q content.
Another user who trusts his signature can then trust files signed by him.

In the simplest case, this system would consist of a separate database of
content signatures. When you get a search result from the servlet you're
interested in (which contains a filename, size, and CRC) you do another
search (perhaps in another network altogether) to find signatures for that
file and public keys to verify the signatures with. Each key represents an
individual, and each signature represents a public certification made by
that individual about that content. Without a web of trust, all I really get
from this is a cryptographically strong way of tying identities to content
certifications. I have no idea how trustworthy the identities are.

This simplest case can be easily attacked -- I'll build onto it soon.
Obviously, just as quickly as I can create signatures that certify good
content as good and bad content as bad, the 'AIAA' (attacking Industry
Artists Association) can create identities and signatures that certify good
content as bad and bad content as good. So I've only gained ground if an
arbitrary user can learn, either from a web page or IRC or whatever...that
signatures made from my key are accurate and signatures made from other keys
are always inaccurate. The target audience isn't going to want to find and
add their own content certification keys.

A more realistic example would implement a web-of-trust. We now have key
signatures as well as content signatures: in the keyring management section
of my client, I can investigate the keys I know about, by searching for key
signatures for the key in question. My which-keys-can-I-trust problem is
still there, but easier to overcome now: if we have a few definitely-trusted
keys (like the original authors of Gnutella, or known information freedom
advocates), those keys can delegate trust to people by signing their keys.
Big deviation from the PGP web of trust model here: in PGP you're merely
certifying the ownership of the key when you issue a signature. How much you
trust an individual is never published by PGP. In the system being discussed
here, you are interested in trust more than identity, so you publish trust
information. Trust is published by issuing a key signature certificate out
into the network, and it's revoked by issuing a key signature revocation
certificate.

A client can verify a given key's trustworthiness by the signature path from
the known-and-trusted keys. If a key is signed directly by a
known-and-trusted key, it's also pretty well trusted. If a key is signed by
someone who is signed by someone who is...eventually signed by a trusted
key, trust will be established, but with lower confidence. Most likely, the
given key will have many many signatures with a fault-tolerant signature
path leading back to the trusted keys. If we suppose that one of the
original trusted keys' "trusted lieutenants" (keys signed directly by one of
the original trusted keys) were to go bad and start signing AIAA keys and
start certifying bad content, the original trusted key owner would revoke
the trust granted to that individual. All keys signed by that individual
would no-longer benefit from that individual's trust. That doesn't mean they
become untrusted...but we should hope they have some trust-granting
signatures other than derived from the bad individual...because the bad
individual's signature is no-longer meaningful.

This model is more likely to survive attacks. Keys that create bad content
signatures simply never get marked as trusted. Keys that were once trusted,
but have now began creating bad content signatures and signing other bad
keys, have their signatures revoked and are no-longer trusted.

This trust network can be self-starting, also. The client software should be
able to catalog all of the content and key signatures made by a key. If a
particular client can directly measure the 'decisions' made by a key --
checked that its files really are the way it claims they are, and checked
that the other keys signed by this key seem to be trustworthy (ugh,
recursion) that client can decide to trust that key (partially or
completely), thus making another 'root' of the trust tree. To put it another
way, the client could also compare the decisions 'influenced' by a key --
which content signatures would become trusted if that key was trusted -- and
compare those content signatures to the overlapping content signatures made
by the existing trusted network...the client could measure how trustworthy
the key might be.

In practice, it seems silly to require processing several public-key crypto
operations and finding and downloading many key certificates and files, to
tell whether a given content file is worth downloading or not. However...we
don't have to use Gnutella to transfer keys and signatures: I imagine
Freenet might be more appropriate for this kind of content. (So yes, besides
adding the GPG source to Gnutella, I'm proposing merging Gnutella with
Freenet someday, using Freenet for key distribution.) Also, each client will
need to keep a keyring, retaining the keys and signatures that pertain to
the content it's downloaded and the keys it uses frequently.

Assuming a trust network that fans out quickly, with each influential key
signing dozens of other keys instead of two or three, it may only require
three or four dips into the distributed keyserver to verify content. The
client could verify content in the background...coloring a search result's
icon from red to yellow to green as it gets more of the key and certificate
material it needs.

The only major concern left is privacy and anonymity. These keys are
personal identities: for a key to be effective it must be maintained by one
person. However, the key and the identity might not be obviously-related:
the network won't expose where a key's signatures are entering the network
from, and keyring files must be seized or stolen to confirm that any given
identity belongs to a specific computer. In addition to that, these keys can
be detached from their identities if the owner destroys his private key. The
existing signatures made by that orphaned key still stand and are still
meaningful, but nobody can tell what individual once owned that key.

It is probably not illegal to help maintain a web of trust. It's probably
illegal to host the content directly, and it might be somewhat illegal to
directly publish signatures that confirm that someone else's content is what
it claims to be (affirming to the world that you personally downloaded the
content and confirmed that it was good). However, it's probably not illegal
to sign someone else's key, attributing trust to them. All you're really
saying is that you trust them to sign only good content -- and you have no
idea whether that content is legal or not.

In the Gnutella interface, this web-of-trust system would probably be seen
as a key-management screen, a content-rating screen, and as trust levels
displayed next to each search result. In the content-rating screen you could
look at the content you have downloaded and rated (good/bad, or several
more-specific ratings), and who has signed the content. In the
key-management screen you could look at the keys you know about, what
content the keys affect, and how your ratings compare with trusted or
untrusted keys' ratings. When you get search results, a summary content
rating can be displayed next to each search result. The system can calculate
ratings either on-demand (right-click -> Investigate) or automatically (i.e.
search results returned < 50), and can explain and graph those ratings for
you (I trusted this file because these people certified the file.)


This file represents a vision for the kinda-distant future...but it will be
realized only if people get excited about it and work to implement it. If
you personally don't understand part of the discussion presented here, or if
I forgot to explain something, or if something doesn't make sense, please
post here in the forum and/or email me at gne...@ms....

Thanks for reading. This idea is *yours* now -- please do your part to help
it become reality.

-----End snipped post from GnutellaNG message board-----


This is a LOT to chew on, and my ideas have evolved a little since then...

this idea is posted here for everyone's benefit -- if any individual reader
has questions or comments, or doesn't understand something (because not
every code hacker on the planet has used GPG...don't feel bad, we won't
blame you) please feel free to reply publicly or in private email.

Thanks!

--Michael Spencer
bl...@ms...
(person running that public server, 209.180.104.204:9912)