[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.
---eric
Other related posts:
