Icon of a thin page Icon of a thick page

Nifty HashCash

David A. Harding

Today, in fact these last couple've hours, I started playing with a little program called hashcash. The idea is that it forces you to expend a "parameterizable amount of work to compute" a small text string that can be quickly (read: instantaniosly) checked. So, for example, when I want to send an email to you I use 10 seconds of CPU time to generate this string which effectively certifies that the email is not spam. If, like me, you have a bunch of questions after a bold statement like that I suggest reading the hashcash FAQ.

All of this being free software I grabbed a copy of hashcash and a smallish perl wrapper script around sendmail that I told mutt to use. It's completely transparent to me; the perl script accepts the email, forks to run the hashcash calculations while the parent returns, after the calculation is done it inserts the X-hashcash header(s) and then passes the mail off to the real sendmail. I'm using a long 26 bit collision (20 is the default) and it takes about 45 seconds to compute (for each receipant) but with the fork() and all I don't really notice.

The bad news is that I don't expect major web-based email providers to ever deploy this technology. The good news about the bad news is that there are very few cool people using those sites so their inablitiy to use hashcash doesn't really matter to me. It's worth noting that SpamAssassin (SA) >3.0 has built-in support for checking hashcash headers; SA assigns a score from -.5 (20 bit) to -4 (>25 bit); the SA webpage calls them "bonus points" for helping get your legitimate email through.

Sorry for putting you through all of that, anti-email-spam stuff is pretty boring these days. I for one am happy with my current setup. What I really find interesting is the potential for using hashcash in other applications. For example, when I roll out the feedback for this here blog (hopefully this weekend) I plan on using hashcash as an anti-spam measure. Moving away from spam, I find Reusable-Proofs-Of-Work (RPOW) to be very interesting.

Enough talk, here's a quick example for, say, email:

dave@callisto:~$ time hashcash -Cb 23 -m email-to-you@your-domain.net
hashcash token: 1:23:041113:email-to-you@your-domain.net::+yWesvmHnvT4jgnY:000000000000000000000000000000000jwtM

real    0m8.167s
user    0m8.131s
sys     0m0.013s

dave@callisto:~$ time echo -n \
1:23:041113:email-to-you@your-domain.net::+yWesvmHnvT4jgnY:000000000000000000000000000000000jwtM | sha1sum
0000007735d8442e7ed89ff5525aa0d35b2a5fcd  -

real    0m0.003s
user    0m0.002s
sys     0m0.001s

Note the leading zeros in the SHA1 sum—that's how hashcash manages it, the "stamper" creates hundreds of thousands of strings in that last colon-delimited field (using a counter so your memory doens't explode) until a collision with the proper number of leading zeros is found. You just need to verify that the "resource" field (in this case an email address) matches something unique to you and that the SHA1 hash has the proper number of leading zeros. Nifty.