[hashcash] Re: hashcash 1.0-pr3
- From: Justin Guyett <justin-hashcash@xxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Tue, 1 Jun 2004 15:29:49 +0000
On 2004-06-01T05:46:17-0400, Adam Back wrote:
> btw do you mind if we forward this discussion back to hashcash list?
I'm sending this reply to the list.
> On Tue, Jun 01, 2004 at 12:15:39AM +0000, Justin Guyett wrote:
> > On 2004-05-31T19:41:27-0400, Adam Back wrote:
>
> > > So one possibility is to implement some example extensions. I was
> > > thinking a small, bare public with DSA could be 171 chars (1024
> > > bits/6).
> >
> > I just don't see why extensions that aren't relevant to evaluation of the
> > hashcash stamp are being put into the hashcash stamp. The stamp isn't
> > encrypted or signed, which are the only two reasons why cramming other
> > stuff into it would be useful.
>
> Well ok here's the difference. The hashcash stamp is kind of
> authenticated in some weird way. As you say not encrypted or signed
> because there is no sender or recipient key. However never-the-less
> it is perhaps interesting to authenticate headers, extensions etc as
> being the ones chosen by the person who expended the x-seconds work to
> create the stamp.
For some reason, that wasn't completely registering before regarding the
stamp value field, but another kind soul jump-started my brain.
A sender can't gain from putting arbitrary values in the collision-bits
field in v1. More importantly, the sender can (and will, 50% of the time)
lose stamp value because of that field. As long as there's no metric of
"good" and "bad" keys, what can the sender possibly lose by sending an
arbitrary base64 string rather than a base64-encoded public key?
So am I thinking about this properly? Is there an advantage to including
in the stamp fields not useful for computing hashcash stamp acceptance?
> Kind of a weak binding as anyone else will to expend another x-seconds
> could change the field, but a binding none-the-less.
>
> Of course the value coming from this is dubious probably already for
> CAMRAM because if an attacker can modify stuff, then games over for
> CAMRAM I think because they eg rely on unauthenticated email
> challenge-response option. Someone who could modify headers could I
> presume read messages and probably just send a forged CR response.
>
> So this is an interesting comment. Suggests hashcash extension fields
> should be used sparingly and only by people who actually need the
> value from that auth feature if the rest of their system is high
> enough assurance to support that.
> > I like the idea of sending an initial high-value stamp and subsequently
> > signing with a whitelisted key. Make the stamp cost high enough and add a
> > pgp keyid-based dnsbl, and spammers will quickly find themselves out of
> > business. The key generation cost isn't much (except for 4096-bit dsa
> > keys), but if first-contact stamps have a present value of 32 bits,
> > that'll kill the spammers.
>
> I'm wondered about CAMRAM white-listing on this ground. If you spend
> one 26-bit stamp and spammers can then share a white-list signature
> key amongst a bunch of spammers, and can send the recipient as many
> mails as you want, they might eventually just do that: use their
> zombie armies to actually "introduce" themselves.
>
> Well probably not something to worry about now, and if it gets to that
> stage, lots of field lessons will have been learned (hashcash would
> have to be pretty widespread for spammers to bother doing it) and
> perhaps it will be clearer by then what to do about it.
And whatever the result of "zombies vs hashcash," the result of "zombies
vs nothing" would be worse.
With high postage rates (32+ bits), is it feasable for spammers to spend
an hour or three of "zombie" cpu time to generate a stamp when it only
takes some irate user 5 seconds to forward the message to a special
address where a script reports the signing keyid to a dnsbl blacklist? If
so, raise the intro stamp cost even more to 34, 35 bits... At some point,
spammers will give up. Lower the stamp cost.
People who really hate spam can be part of high-postage social networks.
If there were some application (like camram) that supported reverse stamp
costs and updated local stamp costs automatically, a network of
reverse-stamp-enabled users would automatically raise postage rates in
response to a MS virus (and zombie network) outbreak, and gradually lower
rates as machines got cleaned up.
Oh, and what about the web of trust features in pgp? It seems like that
could be used to great advantage to get into a high-postage social network
without spending days computing an intro stamp just to get marginally
trusted by one member of the network. Of course, that requires user
intervention...
--
"Not your decision to make."
"Yes. But it's the right decision, and I made it for my daughter."
- Bill, Beatrix; Kill Bill Vol. 2
Other related posts:
