[hashcash] Re: Opportunistic signatures - a proposed design

Atom 'Smasher' wrote: 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, 30 Aug 2004, Eric S. Johansson wrote:

Hashcash is wonderful for lots of things. Unfortunately, it really really sucks for mailing lists because mailing lists are behaviorally just like spammers (lots of mail in a short period of time). 

===================

huh? if you send a message to hashcash@xxxxxxxxxxxxx (a mailing list) then you mint a stamp for that address.

as a subscriber to that list, i tell hashcash to accept any stamp minted for <hashcash@xxxxxxxxxxxxx>, and consider it just as good as if it were minted for me. that's covered in the FAQ, question 5d.

I see that as a spammer hole. either by mailing through the entire list or through collecting addresses of active participants, one can use that logic as a way of enabling parallel double spending. not to mention problems with distinguishing when the use the mailing list exclusion vs. not. A third failing is the ability to forge a message to make it look like it comes from the mailing list.


It's also unreasonable to impose the hashcash burden when communicating to someone you know. 

=====================

it may or may not be. i'm not using the world's best computer here, but a 20-bit stamp for everyone isn't too big a burden for me. moore's law will also apply to legitimate user's of hashcash ;)

I'm on the fence on that one as well. But the enterprise argument is the pushes me in the direction of saying it's unreasonable.

To get large-scale acceptance, we'll need an approach that meets enterprise needs. Most enterprises will not touch a solution that requires large-scale desktop modification. The support burden is just too high. Therefore, we'll need a solution that can be implemented by a "drop-in box". Which is difficult because enterprise e-mail looks just like a spammer for the same reason that mailing lists do. 

==============

i'm not sure i understand how this creates a problem... the bar is raised, for both mass-mailer and spammer... a legitimate mass mailer can create a mailing list and allow subscribers to accept stamps for that list. a spammer will be slowed down to a crawl, or slower.

i also don't see how a public key system is any easier to implement, in enterprise environments, than hashcash.

regarding desktop modification: like nearly all good idea, this will be implemented first in open-source and geeky applications. after 1) people realize that it helps fight spam and 2) someone creates a slick (invisible) interface that's idiot resistant, then all of the closed-source applications used in enterprise environments will have to adopt it, or risk losing market share. the companies will inherit the technology during their next regular software upgrade.

at the egress point for any aggregation of any number of e-mail users, traffic patterns start to look significantly like a spammer. The greater the aggregation, the greater the likeness.

now I am not talking about the mass mailer. I'm talking about the ordinary organizations such as the typical 500 person or larger size company using e-mail to communicate with customers and suppliers.

I state again that a significant philosophical point should be that the ordinary communications between two parties should not be slowed any more than necessary. this philosophical point is why I'm arguing for something other than hashcash for known party communications. Today I use simple white lists. I want something better.

as for ease of implementation, well, I have a 0 user interface white list working today. the only thing not robust is the feedback mechanism to say something got through and that's just going to suck solving that one.

a public key solution should be of similar complexity and user interface requirements. I've got the state machines worked out of how to handle 80 to 90 percent of the cases and if you make the assumption that any remaining cases fallback to hashcash, it should work OK.


anything that satisfies this requirement will violate the above requirement: enterprise systems are slow to change.

that may be. But I do believe that a box sitting in front of the mail server will be more acceptable than changing every desktop at least in the short term.

no need to wait for the technology advanced troops to pick up on something for it to be generally useful.


there is an unparalleled risk factor created when signatures happen on auto-pilot. public key systems will only result in "signed spam". there would be less spam getting through on a daily basis, but when a machine is cracked before a holiday weekend, and there are 100 people in the address book, those 100 people will likely suffer a DoS from the signed spam they're getting. it's debatable whether that's better or worse than a filter that let's 5% of spam through every day.

which is another argument for the more secure box sitting in front of the mail server. No matter what you do, if a machine is owned, you are screwed. But the benefits of optimizing communications between known parties is a significant argument for white lists by name or public key.

If you rotate keys on a regular basis, then your exploitation window drops unless of course your machine has been compromised at which point, you are screwed.

If you take care and protect your keys with passphrases or external devices, you are much better shape unless you machine has been compromised at which point, you are screwed

I guess I'm trying to say is if you machine has been compromised, you are screwed no matter what. Either you machine is used as a zombie for generating lots of stamps, your address book is ripped off, your keys are ripped off, the data files can be ripped off. And, most people would never know what's happening. They're just screwed.

Still, I'm hoping that there's some way that we can optimize mailings for known parties and mailing lists that doesn't require forgery friendly interpretations of stamp usage.

---eric

Other related posts: