Re: Opportunistic signatures - a proposed design

-----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 [email protected] (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 <[email protected]>, and consider it just as good as if it were 
minted for me. that's covered in the FAQ, question 5d.


> 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 ;)


> 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.


> So, if there is a different solution that lets us create "exemptions" to 
> the hashcash load without giving any advantage to spammers, I would like 
> to hear about it.  Personally, I believe that some form of public key 
> solution is the right one.
>
> I believe this because it's a well understood technology with manageable 
> risk factors.  Taken further than signatures, it increases overall 
> confidentiality of communications without requiring any user 
> involvement.
==============

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

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.



         ...atom

  _________________________________________
  PGP key - http://atom.smasher.org/pgp.txt
  762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
  -------------------------------------------------

 	"Everything that can be invented has been invented."
 		-- Charles H. Duell,
 		Commissioner, U.S. Office of Patents, 1899
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.6 (FreeBSD)
Comment: What is this gibberish?
Comment: http://atom.smasher.org/links/#digital_signatures

iQEcBAEBCAAGBQJBM1YVAAoJEAx/d+cTpVciZOMH/0M/WiiYwGPWsdxlNvz8ICu4
VvKbe5q8Qn08K6RW3j1/aHEaFz4MOzeIMmPm7MRSmHrFv65IxDFYa0sPwqoC5XQg
B3rellyl201HBZjYIynwmLDB0jHh6Ogykjicdk+uYUS8+TLpwxuWwZhyHu8YwpxB
wPeLhFuTfAlOEdKrepNQAH9d+DL+Q7kPatI+MzPtIEJ3HjoHNKTh63Xb0cAv3sAM
f4zL+poif2fmE01mVIzgJLjBG6xTCvwOkmshQBapTqB0eyd3V4vfONHUI/63oj4q
TOuLELu8b+kEsi5sfPO916IwduXE2JfjC7mDXbZ5wC91yeDNKLnjnTzZTDZnQOo=
=+FI0
-----END PGP SIGNATURE-----