[hashcash] Re: hashcash v1 questions

  • From: "Eric S. Johansson" <esj@xxxxxxxxxx>
  • To: hashcash@xxxxxxxxxxxxx
  • Date: Mon, 31 May 2004 23:02:05 -0400

Hubert Chan wrote:

It all depends on what you're trying to achieve with crypto, and what
your attack model is.  If you just want to verify that the person who
is emailing you today was the same guy who emailed you last week, you
can be a lot more lax than if you want to make sure that the email you
got really was from the Linus Torvalds who wrote the Linux kernel.

I think you understand what I'm trying to do. :-) I'm going for the lax approach. It's the same thing we use for dealing with day-to-day business communications issues. Which, I will admit are susceptible to social engineering but the longer you know someone, the harder it is. And yes, I will have the same problems when people change jobs etc. as we do updating our address books, cellphones, and PalmPilots etc.

And I don't think that human factors is the reason we don't have
widespread crypto.  The thing is that most people just don't see a need
for it.  (Here.  I'll GPG sign this message just for fun.)

we could have an interesting conversation over a ginger beer. :-) I will argue that if you were to embed crypto into your e-mail system at the client level such that there was little or no user interface required, but demonstrable benefit, people would use it without a second thought. Start requiring passphrases and additional end-user client to human interactions and quite frankly, they will look for that check box that says "turn it off".

on a personal level, I do not sign any of my messages or even use PGP anymore because I have about three or four keys that I do not remember the pass phrases for. every time I need to use it, I generate a new key and then after a few months since the last years, the key is useless...
if I had to use PGP on a regular basis, I would need an application which remembered my passphrase for me and did not ask me for it or I would need to write it down in some place I could find easily like under my keyboard (which I forget as well).

P.S.  I don't know much (anything) about the camram model, but how well
does it protect against zombied machines?  Say, Alice's machine gets
zombied by the latest virus-du-jour, and starts sending out emails,
signed with her camram key.

goodness gracious, people seem so obsessed by zombies. I'm getting ready to start calling this project the "net of the living dead".

Seriously, it does not protect against zombies in any way, shape, or form. All it does is make them more visible. In the case of stamp generation, it increases the load on your system which makes it run slower and get hot which will hopefully increase instability. In your example, which is quite a good one, now we have something that is traceable back to an individual even if the key is stolen! Again, you now have a zombie infested machine identified. Once they are identified, they can be turned off, blackholed, or otherwise ostracized.

on a side note, I think hashcash stamps make it possible to use black holes in a rational fashion. instead of using presence on a black hole list as a sign to totally shut off e-mail from a machine, use it to increase your postage requirements from that machine. This allows communications to continue but at a higher cost for the users of that machine. If there's any interest, we could go into implementation details of how this could be intercepted at the SMTP level.


Other related posts: