[hashcash] A summary of the state of play
- From: Jonathan Morton <chromi@xxxxxxxxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Wed, 25 Aug 2004 01:45:45 +0100
To me, this seems like a pretty good case for *large* hashcash stamps
combined with a strongish signature/whitelist system. I've already
described, in outline, how such a system could be designed, though
some
of the details could stand to be tweaked given recent data.
I'd be very interested in seeing that. A summary of where things are
now
(since the goalposts seem to move a little bit every day!). Some points
which have been raised include;
- Minimum stamp postage values (we've had everything from 20-bits to
30-bits proposed!)
- Spammers running powerful minting machines (the stack of Xserves
scenario)
Due to recent advances in CPU technology, combined with my
optimisations, it's now clear that 20 bits is too low - though it was a
reasonable default beforehand. (It's still the default in the shipping
hashcash implementation, but it is no longer reasonable.) 24 bits is
probably the bare minimum, and would probably be appropriate if a "bare
hashcash" scheme were widely adopted. Larger values would be
preferable, but are only practical if there's a way of bypassing the
mechanism for regular correspondents - which there is (see below).
- The 'economic gap' between the Xserve spammer and the poor 486 :)
To some extent, it's reasonable to assume the 486 (or 68030) user is
accustomed and resigned to things taking longer on his hardware than on
others'. As such, he might be perfectly willing to write a mail, then
go away and have dinner while the stamp is minted, and send the mail
afterwards.
This assumption makes sense up to about 26 bits, based on current
performance estimates. Up to 30 bits may also be acceptable, if the
user is willing to wait overnight. But waiting overnight is something
even low-end users would only want to do occasionally.
- Opportunistic signatures (mentioned by eric in his last mail)
- Signature / whitelist system
- Hybrid systems, and where hashcash fits in (e.g. the MS SenderID
proposals, which appear to be gathering pace)
It's becoming increasingly clear that a single technology isn't going
to solve the problem. An intelligent combination of technologies would
be much more effective. There are a quartet of complementary
technologies to consider:
- Proof of work
- Signatures with whitelist
- Domain certificates
- Content filters
Domain certificates are good as a first line of defence for reducing
forgery. This is a highly recommended goal in any case. They can be
implemented at the SMTP level, separately from the remainder of the
filters, which must operate at the message level.
Signatures, and whitelists based on them, can be considered part of the
next line of defence. The most efficient form of signatures I know of
is also very simple to implement - I'll describe it separately. It's
all based on establishing a unique full-duplex conversation.
Note that signatures for whitelisting are far easier to specify and
implement than signatures for message body verification (a la PGP) or
certificates for blacklisting. There is no need for a "web of trust",
which is burdensome to maintain - in fact, it is possible (and ideal)
to make it completely transparent to the user. In this way, they are
also applicable to mailing lists.
Proof of work can be used as either a substitute or a foundation for
signatures. Obviously, it's cheaper for a sender to add a signature
than a PoW token, but if a signature relationship hasn't yet been set
up, the PoW token is the way to go. Hashcash is a good candidate for
PoW.
Content filters are the last line of defence. They should only come
into play if a message passes the domain certificate stage but gets an
inconclusive result from the signature and PoW filters (perhaps because
neither are present). This is the last chance for a message to "go
legit" before it is dropped. CAMRAM implements this technique.
The point of the content filter is to allow the status quo to be
gradually phased out, rather than instantaneously becoming obsolete.
It also allows senders to be partially ignorant of the quantitative
requirements of the sender (ie. PoW value), without necessarily
requiring a message feedback mechanism to avoid excessive false
positives.
- Stamps versus pipe size (again, eric mentioned he had a spreadsheet
with
some volume calcs. I'd really like to see that)
I'll leave Eric to provide this. But, as a ballpark, consider that a
T1 (1.5Mbit/sec) can be had for perhaps $400/month, and a typical
e-mail might be less than 10KB. A typical zombie can be considered to
have 250Kbit/sec upstream bandwidth.
- RPOW (I'd like some background info on this, any links?)
A brief, and perhaps oversimplified, description of RPOW is that it
allows hashcash tokens (which can only be used once) to be exchanged
for "bit gold", which can be sequentially Reused. Whenever "bit gold"
in the form of an RPOW token gets passed from one hand to another, it
is atomically verified and exchanged for an identical-value token, by
contacting a network of RPOW servers.
This means that when someone receives a message with an RPOW token
attached, they can send an RPOW token of equal value out without
spending more CPU time. If they need more RPOW value, they can
generate hashcash and exchange it at the RPOW server. RPOW tokens can
also be split and combined by the server, provided the total value
remains conserved. However, verification of the token requires contact
with the RPOW server, unlike plain hashcash.
At present, there is physically only one RPOW server. The RPOW server
must be implemented within a special IBM "secure cryptographic
coprocessor card", which costs upwards of $3000 - more than an Xserve.
Each card is only capable of about 8 transactions per second.
Evidently, RPOW does not scale to general use of global proportions,
but it may still be useful to help low-end machines "save up" CPU
effort for future messages.
Further information is available from: http://rpow.net/
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: chromi@xxxxxxxxxxxxxxxxxxxxx
website: http://www.chromatix.uklinux.net/
tagline: The key to knowledge is not to rely on people to teach you it.
Other related posts:
