Slashdot Mirror

There are more details here. Obviously, there's more to creating a workable system than this, because such an atmosphere would make it impossible to run a large-distribution mailing list, but it should be possible to get around such problems with a little ingeniuity, such as allowing the recipient of such mail to exempt certain IP addresses at the mail server from having to generate hashcash. My favorite part of this scheme is that, implemented properly, it could stop spam before it leaves the originating ISP.

It isn't money, it's expense. AOL and MSN wouldn't be taking in a dime (in fact they would probably limit each user to some small amount of has cash each month). It has nothing to do with somebody having credit card info on you. It has nothing to do with international correspondence either, except it would be relatively more expensive there - but still negligible unless mass mailing.

If you really were talking about hash cash, I don't see how your arguments apply.

your idea isn't a new one, its over 5 years old.

http://www.cypherspace.org/~adam/hashcash/hashcash .pdf

Hashcash was originally proposed as a mechanism to throttle systematic abuse of un-metered internet resources such as email, and anonymous remailers in May 1997. Five years on, this paper captures in one place the various applications, improvements suggested and related subsequent publications, and describes initial experience from experiments using hashcash.

The hashcash CPU cost-function computes a token which can be used as a proof-of-work. Interactive and noninteractive variants of cost-functions can be constructed which can be used in situations where the server can issue a challenge (connection oriented interactive protocol), and where it can not (where the communication is store and forward, or packet oriented) respectively.

Disclaimer: I am biased because I have a college account. Of the past 547 emails I have received, none of them have been spam. Before that I had a Hotmail account (mike_hamburg at hotmail dot com), which is still open (although I don't check it often), but it receives only about 2 spams a week. Please restrain yourselves from selling me to a list out of spite.

The article is wrong. Spam is a big problem, but it will not "end email as we know it." There are plenty of ways to curb the problem that have not been implemented yet.

The best suggestion that I have seen to curb spam, although it would be hard to implement and people would bitch about it, would be to have a payment based system. Everyone has a contact list of people who can send them mail for free. If you're not on that list, you have to pay a penny to send a message. Since the profit margin on spam is less than a penny per message, no more spam, or at least not much. Hard to implement, but it would work.

Other than that, there's Hash Cash, which could be combined with the above system, to increase the computational load of spamming. Easier to implement, and to get people to switch to, could reduce spam, not a cure-all.

Encryption and digital signatures would be a useful technique too. Require all mail in your inbox to be encrypted with a Diffie key would help, as Diffie encryption is much harder than decryption. This would also increase privacy, although changing the protocol to prevent traffic analysis would be a bitch to get off the ground (although you can get something like this already at Hushmail).

Bayesian spam filtering or other advanced techniques might also help to curb the problem, but they are a bit like a band-aid on a bullet wound. The article is at least right in that spam filters are not the solution.

Your idea is a good one. There are a number of ways that it could be implemented. It would not require micropayments if the payments were not "cashed" when the email is non-spam. One implementation is documented here . There have been several academic articles also.

You can still keep the system open by forcing the sender to spend a little bit of CPU time to send a message (e.g. finding a collision of a short hash function). The idea is explained at:

• http://www.acm.org/crossroads/columns/onpatrol/mar ch2001.html (search for spam)
• http://www.cypherspace.org/~adam/hashcash/

If only the people who got those Perl RSA tattoos could have known...

-B

If only the people who got those Perl RSA tattoos could have known...

-B

If only the people who got those Perl RSA tattoos could have known...

-B

That's correct. There are OTOH projects which do aim to preserve data. E.g. Eternity Service use distributed servers to do it.

The system mentioned here, probably intended primarily for anonymous mail servers and the like, has the server keep a database of spent tokens. If the tokens must incorporate the date or time in some fashion (along with a unique server string), then the database need be no larger than whatever time threshold the server applies (tokens with an out-of-range timestamp are automatically rejected).

If you're not using a gateway mailserver that's inside a network of trust, then sending email would involve computing a different destination-specific token for each email you send, which results in the situation you describe, which Adam Back addresses as 'interactive hashcash'.

I personally prefer interactive hashcash regardless of the delay. If you're on a slow machine, you send an email, continue working, and 5 minutes later you maybe get a note saying the mail was or wasn't sent (or you simply get bounced mail on failure, or whatever). You don't spend the time waiting, unless you're planning to disconnect the net connection or do something processor-intensive right after sending the mail. For sub-10-second delivery you either get a faster box or use a different protocol (e.g. instant messaging).

This could even be used in parallel with existing mail protocols. The presence of a successful hash token could just show up as another mail header line, and users could prioritize mail based on its presence (and the more computation performed by the sender, the less likely the message is a mass-mailing, assuming the sender isn't known to you). If this system became pervasive, tokenless mail would eventually be obsolete.

all of these "darn near impossible to reproduce" crypto systems are just variations on a one time pad .

there is some library and command line tool source available at: http://www.cypherspace.org/hashcash/source/ also there is a windows gui version and a java applet version which is kind of "clientless" for people with java browers. (The camram group are using the java version for senders who don't have a hashcash client). http://www.cypherspace.org/hashcash/

there is some library and command line tool source available at: http://www.cypherspace.org/hashcash/source/ also there is a windows gui version and a java applet version which is kind of "clientless" for people with java browers. (The camram group are using the java version for senders who don't have a hashcash client). http://www.cypherspace.org/hashcash/

• -export-a-crypto-system-sig -RSA-2-lines-PERL
  print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
  )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsX x++lMlN/dsM0<J]dsJxp"|dc`

• -export-a-crypto-system-sig -RSA-2-lines-PERL
  print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
  )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsX x++lMlN/dsM0<J]dsJxp"|dc`

since I didn't see this at messages posted 4/5 I'll assume no one wrote this. This is the most effective solution for spam, will take a couple months to implement.

- change the mua only accept email from ppl in the address book. This can be done (and I will do it as soon as I get a computer) for mozilla/evolution without too much effort. Optionally accept pgp messages sign to individual from any address (a method of hashcash)

- invitations 2 join persons addressbook will be via a server application that verifies the random new persons email by sending an email to them. so u will get a email saying: "person john doe wants to be added to your address book: here is his info". If it's spam, then you have the email account of the bum who sent it 4 sure...

complicated a bit.. need to write it up.. but I'll do this for my family/friends, and maybe it'll catchon, but best thing is that it doesn't need to... I'll be 100% spam blocked in a day, and I don't need 2 worry about false positives...

I'm not saying it's worthless -- it most certainly is not. However, my inbox is already clean after configuring exim to use all public blacklists I know of, and delivery going through a weighted score system in procmail, so at this point I'm (again, other people might have more severe spam-problems than I) more interested in methods to stop the spammer from even talking to my mailer.

I'd have no problem switching over from SMTP to something more secure if that is what it takes (and I believe it is). Maybe hashcash? I don't know.

Yes

It's difficult to tell what will be the attributes of any method that will exist, but it's not hard to give requirements. I'll use the word "spyee" to mean the person whose data is being stored.

* First of all, it cannot be done without people's permission. Every single piece of info that is stored MUST be there with the spyee's knowledge and consent. If someone wants to store their sexual preference or medical records, etc. etc. let them, but don't reqiure me to tell you my SSN / Credit Card info.

* Second: It MUST be distributed. This is because it can work iff (if and only if) the spyee retains ownership and complete rights to his data. Nobody else can even think for a minute that they own it. Even if they store it. It's paramount that each spyee's info be broken up and different chunks stored on different computers. In this sence, it would work like The Eternity Service (here's even more info) or (my favorite), Freenet.

*Third, Every piece of info must be stored encrypted. Let the user's browser have a session keys. Let the user have a few keys. That way, the user can access his data (with the help of front-end programs) and he can have a stupid form filler, but the company or Skriptkidd1e can't use it.

*This MUST be a subscription service. I believe that it would be far too expensive for advertising to be the source of driving revenue. The storer MUST NOT be able to sell the data, thus depriving him of that form of revenue as well.

*The user can pay the same way as payment worked in ZKS FREEDOM - The user bought an activation number and used it to buy the service - but the end user name _cannot_ be traced to the person who bought it (Hence "zeroknowledge"). It was awesome!

This can be accomplished quite easily, and built in to any UI so that working it requires minimal gray matter. I think that the best way would be to store it on freenet. It takes care of all the above problems, but introduces one of its own: data expiration.
Reply and tell me what you think, this topic is fascinating.

Primarily I'd add a hashcash payment system. Where in order for you to send me a message [that I would eventually see] you *must* do some work [e.g. find an N-bit collision].

I agree completely. Dumb network, smart nodes.

For those not familiar with hashcash, see the following: http://www.cypherspace.org/~adam/hashcash/

Yours truly,
Mr. X

...build a better filter...

Steps in curing email spam

1. Close all open relays. That way the route of email is from your ISP to their ISP. [well at least as far as SMTP is concerned]

2. Use a HashCash like system.

3. Actively deny connection from IPs that try to connect more than N times in L seconds.

Duh...

I think these senators don't comprehend the reality with spam; that is, 99% of it has false origin information and has an opt-out scheme that doesn't work or only results in more spam.

However, I don't believe in making laws against spam. They'll always be outdated and interfere with legimate uses of email, since it can be very hard to define exactly what is spam. (Someone taking my address from a newsgroup posting and trying to sell me printer toner is spamming, but how about an email from a company I bought something from a year ago?)

Adam Back has an interesting proposal called Hash Cash. The idea is that if you want to send me an email, you have to burn some CPU cycles to compute a partial hash collision. I choose how many bits are required. Friends and family can send me email for free. I'll charge a few bits for the store I shooped at last week, and even more for people I don't know. If you're in ORBS or MAPS, perhaps I'll charge even more.

I think these senators don't comprehend the reality with spam; that is, 99% of it has false origin information and has an opt-out scheme that doesn't work or only results in more spam.

However, I don't believe in making laws against spam. They'll always be outdated and interfere with legimate uses of email, since it can be very hard to define exactly what is spam. (Someone taking my address from a newsgroup posting and trying to sell me printer toner is spamming, but how about an email from a company I bought something from a year ago?)

Adam Back has an interesting proposal called Hash Cash. The idea is that if you want to send me an email, you have to burn some CPU cycles to compute a partial hash collision. I choose how many bits are required. Friends and family can send me email for free. I'll charge a few bits for the store I shooped at last week, and even more for people I don't know. If you're in ORBS or MAPS, perhaps I'll charge even more.

In my experience so far, the only way to run a fairly spam-proof SMTP server is to be utterly ruthless with blacklisting. Blacklist insanely large portions of IP space, but configure your SMTP server to produce a bounce message which describes a way around the block (like a postmaster address, or something). A legitimate sender should receive and read the bounce (unless they have one of those ghastly SMTP servers which discards error message text and "helpfully" translates it into "the user does not exist"), whereas a spammer is likely to ignore it. If someone responds to the bounce message in the manner described, whitelist the associated IP address. Spammers send out so much mail that they can't attend to every bounce message personally. (And contrary to some opinions I've seen expressed elsewhere in this article, I've yet to see any evidence that spammers remove addresses which consistently bounce.)

Another possibility is to use the "MAIL From:" address: construct a whitelist of names from whom you will accept mail, and bounce all the others with a similar "how to get around this" message. As before, add the address of any such person who reads the bounce message to your whitelist. Note that both of these techniques could, in principle, be automated. Note also that although a spammer can trivially forge the "MAIL From:" address, it's not nearly so trivial to match every "RCPT To:" address with a whitelisted "MAIL From:" address.

I don't pretend that the above approach to spam-blocking is polite, but rather that it's the only one I've found to be very effective, given the limitations of SMTP. Most people are quite horrified at the number of IP addresses I blacklist: one spam from an open relay is usually enough to convince me to blacklist that IP address at the class B level (approx 65,000 IP addresses in its neighbourhood). It's not about raw numbers, though: it's about the impact that it has on your mail service. If I'm never likely to receive a legitimate email from that IP range, then why not blacklist it?

Ultimately, though, the solution will be to replace SMTP with a protocol that recognises one simple fact that SMTP does not: parties engaging in mail exchange are potentially hostile to each other, and thus the protocol must only allow progress when there is mutual agreement between the parties that the transaction should go ahead. IM2000 is an interesting and potentially useful proposal, for example, albeit a bit short on details (and stagnant, judging by the recent lack of traffic on the mailing list). As it happens, I've chosen to make this problem (replacing SMTP) the subject of my Honours thesis, and that's due to be finished by July. Whether or not my proposals will actually be adopted by anyone is a different matter, of course.

GCP says: Perhaps we could also use the "plus convention" to allow users to effectively manage their own email address(es). Many servers are set up so that if my assigned email address is fred@foo.com, then fred+[anystring]@foo.com is still sent to fred. Tell your friends to address you as fred+friend@foo.com, and then have your client sort the "+friend" messages into a friends folder.

I think that's a good idea, but only a short-term solution. If it ever becomes wide-spread, spammers will just use brute force and send emails to fred+%dictionary_word@foo.com. It wouldn't even be that hard - most likely, people would somewhere accidentally post their "secret" email address (which happens right now) and a spambot would pick that up. Above that, most people would use common words, "secret", "spam", "free", etc. There would be huge incentive to break the system for the spammer - if they're the first to find out how to bypass the secret system, their spams are able to be read by everyone, while other spams will be filtered out. It'll simply be a race to be the first spammer to be "heard".

The solution must inevitably be, in my mind, to make spam cost something. Not necessarily money, but some sort of tangible resource. Various solutions have been proposed, all of which in my mind are not completely up to the task. However, they're the only effective long-term solution. So long as spam is free, there's no disadvantage to sending 1,000,000 emails to get one responce. I personally like Adam Backs' Hashcash program, which is at www.cypherspace.org/~adam/hashcash/> . However, the site seems to be down at the moment, so one can use Google's quite convinient cache of it at http://www.google.com/search?q=cache:-g8yVfQ3vFwC: www.cypherspace.org/~adam/hashcash/.

Perhaps we should start password protecting our inboxes in that to send me an email you have to supply a password.

Ahh, but if they spame nicely then they will have valid return-email addys, won't they? Or optimally, an X-UCE header, or some such.

Or, as the California and Colorado state laws require, the Subject header begins with "ADV:", although this is incompatible with some other spam laws.

I still think per-address-pair hash cash is a better solution; see the LAPO hash-cash demo applet for a simple hash cash generator implementation.

Why bother?
Just print the code in a book (or even use the 3-line RSA algoritham on a bit of paper) and it was perfectly legal to export it from the US (freedom of the press).
This is how the international PGP versions were legitematley exported, and then scanned in using OCR to get the code in an electronic format again.

This was partly why the law was overturned. What is the point in banning the export of code in an electronic format, when it was perfectly legal (first amendment) to export in a writen format.

Here's an interesting method of reducing spam called HashCash:

"Hash cash is an electronic payment system based on spent CPU cycles computing partial hash collisions. It finds particular use as a system for reducing unsolicited mail by requiring senders to include a small "payment" with each message.

Basically, you have to spend a certain amount of CPU time to send each message so sending large amounts of spam requires much more work. The reason n-bit partial hash collisions are used "is that they can be made arbitrarily expensive to compute (by choosing the desired number of bits of collision), and yet can be verified instantly." Sounds like an interesting idea, no? They've even produced a high rate of inflation for HashCash because of Moore's Law. Plus it has a funky name

--jobby

Here's an interesting method of reducing spam called HashCash:

"Hash cash is an electronic payment system based on spent CPU cycles computing partial hash collisions. It finds particular use as a system for reducing unsolicited mail by requiring senders to include a small "payment" with each message.

Basically, you have to spend a certain amount of CPU time to send each message so sending large amounts of spam requires much more work. The reason n-bit partial hash collisions are used "is that they can be made arbitrarily expensive to compute (by choosing the desired number of bits of collision), and yet can be verified instantly." Sounds like an interesting idea, no? They've even produced a high rate of inflation for HashCash because of Moore's Law. Plus it has a funky name

--jobby

Technically, it would be possible to create hashes for different pieces of the message, which can be combined in one single "signature" to detect potential matches. It would be more complicated for the catalogue server to execute searches, and the answers won't always be absolute (e.g. partial match).

You would have to define in advance what a "piece" of a message would consist of. Then the spammer simply puts the extra space, unique charachter, etc. in each "piece" of the message. Then, curiously, morzel is still receiving spams despite his/her modified spam blocking approach.

The central problem is whatever heuristic they use to define what a spam is, it has to be predefined and well known. This would imply the spammer would have knowledge of said heuristic and would be able to form his emails in such configuration as to avoid detection.

An AC has replied to your post as well suggesting a incomprehensible replacement which at one point says doing preprocessing on both the spam and the mail Ok, buddy and you are going to force the spammers to properly preprocess their mail so that it will get blocked by the mail server filter......right.

If you can force people to do preprocessing a much better (and comprehensible) solution is
Hash cash Wherein you force each client to precompute a special value that is costly-enough in terms of CPU cycles to deter spamming. This value can be instantly verified by your client, mailserver, etc. and the email will be summarily dropped if the value is not of the costly-variety. Even if this value had to be checked by the recievers client itself, if a significant aamount of clients were configured not to display the email until the value was verified incentives for sending spam would drop. (hopefully to the point where the effort to send the spam outweighs the return to the spammer)

The algorithm should take something like 30 seconds or a minute to perform on a domain or IP address by an average IRC server, which could cache calculated hashes for speedier subsequent logins from that address. Take the entire IP address/domain name to use in generating the hash and don't reveal any part of the user's real address to other IRC users. This would give roughly 2^32 addresses to guess at, as you mention. The IRC server should only use the IP address of a client to compute the hash as a last resort when a domain lookup doesn't work. This scenario would make it computationally infeasible to generate a lookup database client-side.

Additionally, if a secret numerical seed was used in generating this hash and shared only amongst server operators, the threat of someone generating (or stealing from an IRC server, assuming generated hashes are cached to improve future performance) a lookup database could be softened somewhat by the potential of server operators choosing a new key if a compromise occurs or on a periodic basis. This would make the database worthless. It's similar to the way Unix crypt() fights lookups using 'salt', but this secret key can't be randomly generated because then the hash would be worthless for doing autobans and the like (it'd change every login).

This scheme will decrease in effectiveness as computing strength grows. The only way to combat this is to increase the computing needed to process the algorithm. The algorithm must be adjustable, perhaps by adjusting its key length or by running it more than once.

So, basically, if VWorld can find a one-way cryptographic function where the time required to encrypt can be adjusted periodically and the function can be seeded by a large key provided by IRC operators, I think they'd be better off. Perhaps something like Blowfish run a particular number of times or with a particular key size (to slow it down) over the domain name/IP address, then MD5 over the output from the cipher to get short, consistently-lengthed output for the fake domain name shown to other IRC users.

---

there are a group of us try to define and implement a proof of work postage stamp that is reasonably resistant to attacks by dedicated hardware. The basic cryptographic concepts are explained at:

http://www.cypherspace.org/hashcash/

in a nutshell, a hashcash coin is a nonreusable cryptographic expression of work. The message sender would generate the hashcash coin by spending approximately 10 to 15 seconds of CPU time solving a known mathematical problem. A message recipient would be able to verify the coin very quickly and decide how to handle the message based on the presence or absence of a valid coin.

obviously, there would be a need for a white list filter for mailing lists and people one frequently communicates with as well as methods for handling folks without hashcash capability but we have solved most of these problems and are moving forward.

Hashcash is not intended as a perfect solution to the spam problem but it is a very good way of raising the cost of spam for the spammer.

contact me directly if you want to contribute by generating working code for the first generation implementation of hashcash.

However, I don't believe in making laws against spam. They'll always be outdated and interfere with legimate uses of email, since it can be very hard to define exactly what is spam. (Someone taking my address from a newsgroup posting and trying to sell me printer toner is spamming, but how about an email from a company I bought something from a year ago?)

Adam Back has an interesting proposal called Hash Cash. The idea is that if you want to send me an email, you have to burn some CPU cycles to compute a partial hash collision. I choose how many bits are required. Friends and family can send me email for free. I'll charge a few bits for the store I shooped at last week, and even more for people I don't know. If you're in ORBS or MAPS, perhaps I'll charge even more.

However, I don't believe in making laws against spam. They'll always be outdated and interfere with legimate uses of email, since it can be very hard to define exactly what is spam. (Someone taking my address from a newsgroup posting and trying to sell me printer toner is spamming, but how about an email from a company I bought something from a year ago?)

Adam Back has an interesting proposal called Hash Cash. The idea is that if you want to send me an email, you have to burn some CPU cycles to compute a partial hash collision. I choose how many bits are required. Friends and family can send me email for free. I'll charge a few bits for the store I shooped at last week, and even more for people I don't know. If you're in ORBS or MAPS, perhaps I'll charge even more.

• export-a-crypto-system-sig RSA-2-lines-PERL
  print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
  )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]ds Xx++lMlN/dsM0<J]dsJxp"|dc`

Seriously, though, is it?

Alex Bischoff
---

http://www.cypherspace.org/~adam/uk- shirt.html

http://www.cypherspace.org/~adam/uk-shirt.html if you're goatse.cx-phobic.

Never mind that dead link I just posted. This is the real thing, with an address and pricing. Sixteen bucks for t-shirt or XXL sweatshirt.

-grendel drago

this is of course not a new idea ... it's been done in the crypto world a few times already ....

Crypto is no help because you want to limit the number of identities someone can have, and yet you don't want to put any hurdles in the way of new customers.

Why not use hash cash? Each user will need to generate a hash cash token to identify themselves, and any given token can be banned. Since it is expensive to generate a new hash cash token, this will thwart such abuses.

obviously i meant http://www.cypherspace.org/

http://www.cyperspace.org

contains some technical details/designs that give some more insight into how, from a technical standpoint, this concept could have been implemented. quite a fascinating read, especially with the whole havenco story.

Hi there,

I was wondering if you could comment about the Freenet mission: how do you see this software affecting the world. I notice that files on freenet will disappear after disuse, for instance, since it is more of a distributed file cache rather than a data haven.

Some similar projects are clearly aimed at the distributed data haven issue, such as The Eternity Service, which due to nigh permanent cacheing is clearly aimed at a distributed data haven type problem domain, or intermemory which takes an approach somewhere in between the cache/haven solution.

So what all do you expect to see the distributed file cache used for?

Great work...keep it up! (BTW, if readers are interested, there exists a nice collection of information on these projects)

Mojotoad

I recommend people take a look at the projects listed at http://www.cypherspace.org/links.html and http://freenet.sourceforge.net/.

As good as Cryptonomicon was, I get more and more convinced that a bunker-style data haven is the wrong way to go.

Why not make the data haven nuke-proof like the internet itself?

Anyway, if you're interested in this paradigm, check out the following projects:

Intermemory
The Eternity Service
FreeNet

And try cypherspace for a nice collection of related links.

Mojotoad

See http://www.cl.cam.ac.uk/users/rja14/eternity/etern ity.html (html version) (ps version)
All theoretical though.

Closest to implemented is: http://www.cypherspace.org/~adam/eternity/ and read about it here.

See http://www.cl.cam.ac.uk/users/rja14/eternity/etern ity.html (html version) (ps version)
All theoretical though.

Closest to implemented is: http://www.cypherspace.org/~adam/eternity/ and read about it here.

The Eternity project already does this (implemented a slightly different way, though)

There are technological solutions to these attempts at bullying. See http://www.cypherspace.org/~adam/eternit y/, for example.

</sarcasm&gt

On the opposite side of the coin, some people are working on making web stuff MORE anonymous. See Adam's Page for an assortment of cryptographic projects. Another idea for true anonymous web hosting is at http://www.firstmonday.dk/issues/issue3_4/goldberg /index.html. I've also thought that it'd be fairly easy to make Mozilla read a .tar.gz or a .zip file as a web tree, allowing people to post web pages anonymously on netnews, but that would not allow for long term storage of pages, wheras these other projects would.