Re: document popularity estimation / amortizable hashcash (Re: Hollywood Hackers)
This paper is quite interesting and proposes another method of
metering content [1]:
http://citeseer.nj.nec.com/naor98secure.html
It's proposed in the context of web site traffic metering to determine
site traffic rates (for advertising payment or other applications).
It relies on a trusted auditor, which could become a central failure
point so is perhaps less attractive for file sharing, but perhaps that
could be fixed.
Another problem is that it presumes a communication pattern where the
auditor sends a secret to each user, the user makes a cheap
computation involving the secret to send with each request, and then
the respective server collects all of the requests it gets and does
some computation to arrive at a compact proof that it received some
number k of requests. (The server also receives a secret, but this is
not problematic, it it anyway wants to participate).
On the plus side their approach is not probabilistic -- it gives an
accurate measurement of traffic, it is also not vulnerable to server
traffic inflation, and is somewhat resistant to multiple client and
server collusion. (Though of course any scheme is generically
vulnerable to server traffic inflation -- servers can _act_ as
multiple clients and simply generate the claimed traffic themselves,
or contract other parties to do this for them.)
Adam
[1]
@article{Naor:98:secure-and-efficient-metering
author = "Moni Naor and Benny Pinkas",
title = "Secure and Efficient Metering",
journal = "Lecture Notes in Computer Science",
volume = "1403",
pages = "576--??",
year = "1998",
note = "Also available as \url{http://citeseer.nj.nec.com/naor98secure.html}";
}
On Wed, Jul 31, 2002 at 09:34:35PM +0100, Adam Back wrote:
> I proposed a construct which could be used for this application:
> called "amortizable hashcash".
>
> http://www.cypherspace.org/hashcash/amortizable.pdf
>
> The application I had in mind was also file sharing. (This was
> sometime in Mar 2000). I described this problem as the "disitrbuted
> document popularity estimation" problem. The other aspect of the
> problem is you have to distribute the popularity estimate and make it
> accessible, so I think you want it to be workably compact (you don't
> want to ship around 1 million hash collisions on the document hash).
> Amortizable hashcash addresses this problem.
>
> There is also some discussion of it here:
>
> http://archives.neohapsis.com/archives/crypto/2000-q1/0440.html
>
> Adam
>
> On Wed, Jul 31, 2002 at 04:25:30PM +0200, Eugen Leitl wrote:
> > It should use scarce resources (e.g. crunch) to generate a trust
> > currency in each node, a kind of decentralized mint (nothing
> > crunches quite a few million boxes on the Net).
Re: Hollywood Hackers
On Wed, 31 Jul 2002, A.Melon wrote: > and on the left hand side of the page it says: > > At the moment, we do not support non-Javascript browsers. > > If they are concerned about security, Shouldn't they be avoiding > javascript? Shapiro has a strange love for Javascript. I don't know what that has to do with OpenCM either way, though... In any case, if you were running EROS you wouldn't have to worry about Javascript causing you problems. :P -Jack
Re: Hollywood Hackers
Jack Lloyd wrote: >On Wed, 31 Jul 2002, Steve Schear wrote: > >> Looks amazingly familiar. Could it be, could be, could it be Mojo >> Nation (now MNet http://mnet.sourceforge.net )? > >Or OpenCM (http://www.opencm.org) > -Jack On the OpenCM webpage, it proclaims on the right hand side: OpenCM is designed as a secure, high-integrity replacement for CVS. Briefly, OpenCM provides ... cryptographic authentication and access control,... The OpenCM project was originally started because we needed a secure, high-integrity configuration management system and on the left hand side of the page it says: At the moment, we do not support non-Javascript browsers. If they are concerned about security, Shouldn't they be avoiding javascript?
document popularity estimation / amortizable hashcash (Re: Hollywood Hackers)
I proposed a construct which could be used for this application: called "amortizable hashcash". http://www.cypherspace.org/hashcash/amortizable.pdf The application I had in mind was also file sharing. (This was sometime in Mar 2000). I described this problem as the "disitrbuted document popularity estimation" problem. The other aspect of the problem is you have to distribute the popularity estimate and make it accessible, so I think you want it to be workably compact (you don't want to ship around 1 million hash collisions on the document hash). Amortizable hashcash addresses this problem. There is also some discussion of it here: http://archives.neohapsis.com/archives/crypto/2000-q1/0440.html Adam On Wed, Jul 31, 2002 at 04:25:30PM +0200, Eugen Leitl wrote: > It should use scarce resources (e.g. crunch) to generate a trust > currency in each node, a kind of decentralized mint (nothing > crunches quite a few million boxes on the Net).
Re: Hollywood Hackers
-- James A. Donald: > > The plan, already implemented, is to flood file sharing > > systems with bogus files or broken files. The solution, not > > yet implemented, is to attach digital signatures to files, and > > have the file sharing software recognize certain signatures as > > good or bad. Eugen Leitl > This is completely unnecessary if you address the document with > a cryptohash. An URI like > http://localhost:4711/f70539bb32961f3d7dba42a9c51442c1218a9100 > can only adress a particular document. And then the hollywood hackers flood the system with bogus descriptions of the content identified by the crypto hashes. We still need to implement a reputation system against a hollywood hacker attack, even if we address content by cryptohash, as indeed we should. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG MZ8I0lLVaSkDBqA1K8OWTh4DR9ESyzcVVpf1x4pT 259CijIJardotArHx0YBUaCUfOceX+5jOYxtQ+fXi
Re: Hollywood Hackers
On Wed, 31 Jul 2002, Steve Schear wrote: > Looks amazingly familiar. Could it be, could be, could it be Mojo > Nation (now MNet http://mnet.sourceforge.net )? Or OpenCM (http://www.opencm.org) -Jack
Re: Hollywood Hackers
-- On 31 Jul 2002 at 11:01, Eugen Leitl wrote: > The issue of node reputation is completely orthogonal to the > document hashes not colliding. Reputation based systems are > useful, because document URI > http://localhost:4711/f70539bb32961f3d7dba42a9c51442c1218a9100 > doesn't say what's in there. A claim needs to be backed by > someone (preferably anonymous) with a good reputation trail. Indeed, but the only working nym based reputation system is that hosted by Ebay. Web of trust is not really used much, and Verisign sucks. My proposal was to implement a nym based reputation system for approving content, rather than to assume such a system already exists. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG n2qkcxSdV2kJT9y6SyQ2iP7hz+Loj0n1HsBec+jV 2F6qbHlOzuO9Od/r5ZvGa0vDhRSmH/+EjFcQI8Wtc
Re: Hollywood Hackers
Anonymous wrote: > On Tue, 30 Jul 2002 20:51:24 -0700, you wrote: > >>When we approve a file, all the people who approved it already get >>added to our trust list, thus helping us select files, and we are >>told that so and so got added to our list of people who recommend >>good files. This gives people an incentive to rate files, since >>rating files gives them the ability to take advantage of other >>people's ratings. [...] > A better approach is for the downloader to create his own trusted list, along the >lines of PGP web > of trust. Ideal for exactly this application. The downloader can add and subtract >from the trusted > signer list at will, with no central control. Since one must expect some trusted >signers to get > busted and move to the dark side under court order, such downloader control is >necessary. One practical method that has been, and still remains popular it seems, is a trusted hub approach. DirectConnect, as a more recent example, allows anyone to set up a central hub, and then filter the people connecting to it (e.g. by amount of files shared, or by personal acquaintance), in a very "localised" peer-2-peer group. This is the same tactic adopted by pre-Napster set-ups such as IRC channels, et al. The obvious downside is immediate choice. Obscurity is naturally exaggerated in comparison to a completely open network. However, smaller groups tend to encourage increased validity of files being offered, especially when only a small number of those people are offering it. This obscurity can be countered in a number of ways - chained networking, in that one person can be in many groups and thus has access to a wider range, coupled with an anonymous request/barter-driven facility would decrease obscurity without losing much of the validity implicit in trusted groups. History suggests that even in such fragmented environments, content can travel to as many people in as short a time as an open network. Under this scenario, the opportunities to spread false files are much more limited, as their scope from origin would be more contained, probably averaging 2 or 3 interlinked groups at most. Not perfect, clearly. But it does seem to be the surviving philosophy.
Re: Hollywood Hackers
On Wed, 31 Jul 2002, Anonymous wrote: > Such an approach suffers from the "bad guy" occasionally signing a > good file, thus placing himself on the trusted signer list. This assumes a boolean trust metric. What you need is a trust scalar, and a mechanism to prevent Malory poisoning it. It should use scarce resources (e.g. crunch) to generate a trust currency in each node, a kind of decentralized mint (nothing crunches quite a few million boxes on the Net). Clearly there will be some inflation, as systems tend to get faster these days. The algorithm should resist FPGAzation, too (Mallory is inventive). > A better approach is for the downloader to create his own trusted > list, along the lines of PGP web of trust. Ideal for exactly this The infrastructure needs to be hidden out of view. If you query the net for a specific document, those signed by most trusted parties should come up first. And when you download and sample a document the GUI should offer positive/negative karma buttons for easy grading. > application. The downloader can add and subtract from the trusted > signer list at will, with no central control. Since one must expect > some trusted signers to get busted and move to the dark side under > court order, such downloader control is necessary. > > Problematic is that mp3 and other compression processes do not > generate bit-identical files. Two perfect mp3 files may have different > md5 hashes, for example. A tool for making bit-identical mp3 files Doesn't matter, as long a single good copy gets out & gets amplified. Plus, you can get different cryptohash URIs for minor variations on content, as long they're published by somebody trusted. > from the same digital input is needed, so that a single signed hash > can verify the same file from multiple origins.
Re: Hollywood Hackers
At 11:01 AM 7/31/2002 +0200, Eugen Leitl wrote: >On Tue, 30 Jul 2002, James A. Donald wrote: > > > The plan, already implemented, is to flood file sharing systems with > > bogus files or broken files. The solution, not yet implemented, is to > > attach digital signatures to files, and have the file sharing software > > recognize certain signatures as good or bad. > >This is completely unnecessary if you address the document with a >cryptohash. An URI like >http://localhost:4711/f70539bb32961f3d7dba42a9c51442c1218a9100 can only >adress a particular document. > >If you serve broken content your node's reputation falls through the >floor. > >Note that content is distributed, dynamic, and you have no idea what >you're actually serving. Looks amazingly familiar. Could it be, could be, could it be Mojo Nation (now MNet http://mnet.sourceforge.net )? steve
Re: Hollywood Hackers
On Tue, 30 Jul 2002 20:51:24 -0700, you wrote: > When we approve a file, all the people who approved it already get > added to our trust list, thus helping us select files, and we are > told that so and so got added to our list of people who recommend > good files. This gives people an incentive to rate files, since > rating files gives them the ability to take advantage of other > people's ratings. > > If onr discommendd a file, those who discommend it are added to > our trust list, and those who commended it to our distrust list. > If, as will frequently happen, there is a conflict, we are told > that so and so commended so many files we like, and so many files > we dislike, so how should future commendations and > discommendations from him be handled. Such an approach suffers from the "bad guy" occasionally signing a good file, thus placing himself on the trusted signer list. A better approach is for the downloader to create his own trusted list, along the lines of PGP web of trust. Ideal for exactly this application. The downloader can add and subtract from the trusted signer list at will, with no central control. Since one must expect some trusted signers to get busted and move to the dark side under court order, such downloader control is necessary. Problematic is that mp3 and other compression processes do not generate bit-identical files. Two perfect mp3 files may have different md5 hashes, for example. A tool for making bit-identical mp3 files from the same digital input is needed, so that a single signed hash can verify the same file from multiple origins.
Re: Hollywood Hackers
-- On 29 Jul 2002 at 14:25, Duncan Frissell wrote: > Congressman Wants to Let Entertainment Industry Get Into Your > Computer > > Rep. Howard L. Berman, D-Calif., formally proposed > legislation that would give the industry unprecedented new > authority to secretly hack into consumers' computers or > knock them off-line entirely if they are caught > downloading copyrighted material. > > I've been reading things like this for a while but I wonder how > practical such an attack would be. They won't be able to hack > into computers with reasonable firewalls and while they might > try DOS attacks, upstream connectivity suppliers might object. > Under current P2P software they may be able to do a little > hacking but the opposition will rewrite the software to block. > DOS attacks and phony file uploads can be defeated with digital > signatures and reputation systems (including third party > certification). Another problem -- Napster had 55 million > customers. That's a lot of people to attack. I don't think > Hollywood has the troops. The plan, already implemented, is to flood file sharing systems with bogus files or broken files. The solution, not yet implemented, is to attach digital signatures to files, and have the file sharing software recognize certain signatures as good or bad. This involves scaling problems that have not yet been thought through or implemented. As files get copied around, they would accrete ever more digitally signed blessings. The signatures should be arbitrary nyms, as in Kong, not true names. The files could also accrete digitally signed discommendations, though such files would probably propagate considerably less. When we approve a file, all the people who approved it already get added to our trust list, thus helping us select files, and we are told that so and so got added to our list of people who recommend good files. This gives people an incentive to rate files, since rating files gives them the ability to take advantage of other people's ratings. If onr discommendd a file, those who discommend it are added to our trust list, and those who commended it to our distrust list. If, as will frequently happen, there is a conflict, we are told that so and so commended so many files we like, and so many files we dislike, so how should future commendations and discommendations from him be handled. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG /q4tip27WhKCNEPO0JVoN0d2y8NqKSNyWSZ2yo8T 2mpKzWKpHGt5yFiUzlZZD//qHoWgv8n1ZFJzoJ2l9
Re: Hollywood Hackers
On Tue, 30 Jul 2002, James A. Donald wrote: > The plan, already implemented, is to flood file sharing systems with > bogus files or broken files. The solution, not yet implemented, is to > attach digital signatures to files, and have the file sharing software > recognize certain signatures as good or bad. This is completely unnecessary if you address the document with a cryptohash. An URI like http://localhost:4711/f70539bb32961f3d7dba42a9c51442c1218a9100 can only adress a particular document. If you serve broken content your node's reputation falls through the floor. Note that content is distributed, dynamic, and you have no idea what you're actually serving. > This involves scaling problems that have not yet been thought > through or implemented. > > As files get copied around, they would accrete ever more digitally > signed blessings. The signatures should be arbitrary nyms, as in > Kong, not true names. The files could also accrete digitally > signed discommendations, though such files would probably > propagate considerably less. The issue of node reputation is completely orthogonal to the document hashes not colliding. Reputation based systems are useful, because document URI http://localhost:4711/f70539bb32961f3d7dba42a9c51442c1218a9100 doesn't say what's in there. A claim needs to be backed by someone (preferably anonymous) with a good reputation trail. > When we approve a file, all the people who approved it already get > added to our trust list, thus helping us select files, and we are > told that so and so got added to our list of people who recommend > good files. This gives people an incentive to rate files, since > rating files gives them the ability to take advantage of other > people's ratings. > > If onr discommendd a file, those who discommend it are added to > our trust list, and those who commended it to our distrust list. > If, as will frequently happen, there is a conflict, we are told > that so and so commended so many files we like, and so many files > we dislike, so how should future commendations and > discommendations from him be handled.
Hollywood Hackers
Congressman Wants to Let Entertainment Industry Get Into Your Computer Rep. Howard L. Berman, D-Calif., formally proposed legislation that would give the industry unprecedented new authority to secretly hack into consumers' computers or knock them off-line entirely if they are caught downloading copyrighted material. I've been reading things like this for a while but I wonder how practical such an attack would be. They won't be able to hack into computers with reasonable firewalls and while they might try DOS attacks, upstream connectivity suppliers might object. Under current P2P software they may be able to do a little hacking but the opposition will rewrite the software to block. DOS attacks and phony file uploads can be defeated with digital signatures and reputation systems (including third party certification). Another problem -- Napster had 55 million customers. That's a lot of people to attack. I don't think Hollywood has the troops. DCF
Re: Hollywood Hackers
On Mon, 29 Jul 2002 14:25:37 -0400 (EDT), you wrote: > > Congressman Wants to Let Entertainment Industry Get Into Your Computer > > Rep. Howard L. Berman, D-Calif., formally proposed > legislation that would give the industry unprecedented new > authority to secretly hack into consumers' computers or knock > them off-line entirely if they are caught downloading > copyrighted material. > > I've been reading things like this for a while but I wonder how practical > such an attack would be. They won't be able to hack into computers with > reasonable firewalls and while they might try DOS attacks, upstream > connectivity suppliers might object. Under current P2P software they may > be able to do a little hacking but the opposition will rewrite the > software to block. DOS attacks and phony file uploads can be defeated > with digital signatures and reputation systems (including third party > certification). Another problem -- Napster had 55 million customers. > That's a lot of people to attack. I don't think Hollywood has the troops. I like this scenario: Adam places his copyrighted content on his web site. His friend, Eve, violates his copyright and places Adam's copyrighted content on her site. Hollywood downloads the copyright-infringing content from Eve's site. Eve confesses that Hollywood did so, in a good faith effort to repent from her copyright infringement. Now Adam hacks Hollywood, as authorized by the proposed law. Lawsuits all around.
