[hashcash] Re: hashcash v1 questions
- From: "Eric S. Johansson" <esj@xxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Tue, 01 Jun 2004 08:40:59 -0400
Is it difficult to attach a pgp keyblock to a message? Even if the
message is MIMEd, There have to be 50 MIME libraries out there with either
a bsd or gnu license and simple interfaces. Is there a reason I'm not
thinking of to include the key in the header rather than as a keyblock in
the message body? The receiving side is easy, even without camram. Just
check for sufficient hashcash, check for a camram header indicating an
attached keyblock, and pipe the message to pgp.
actually, the only difficult thing is working with PGP. I have no
problems with mime wrapping or expanding messages. Python is rather
well equipped in that tool space.
reading ahead this morning, I see that Adam and others have made very
good arguments for embedding the key inside of the stamp.
It boils down to this: if you want to make things as invisible as
possible to the user, put the key in the stamp. If you want to
advertise camram and its advantages (albeit briefly) at the end of the
mail message and/or interoperate with existing PGP users (all 6) then go
with a pgp-mime encoding around the message
Ya well, I never said I was a jingle writer either. I'm a far better
---- begin PGP key block ----
comment: camram, it is really great
comment: keeps the spam off your plate
comment: lets good mail through but not too late
comment: hurray! for camram protection
If the problem is that spammers might put 1000 keys in a hashcash-stamped
message, it's easy enough for camram or any MDA to check the number of PGP
keyblocks and puke after it sees more than 2 or 3. The number allowed
could even be dependent on the stamp value. Maildrop can count the number
of pattern matches; procmail might require an external script.
actually, if you have more than one key block, it's an error. If you
get a message from from me and it has more than 1 key block, its spam.
4) low enough computational load so that mailing lists can use this
Is it ever okay to have a list generating stamps in response to
subscription requests? That sounds like a DoS waiting to happen.
that is indeed a worry. The basic protocol was going to be based on the
normal user to user stamp/key FSM since it is difficult to distinguish
between mailing lists and ordinary e-mail.
If there were a standard way to include advisory return-postage in the
hashcash header, the protocol could go like this:
1. initial subscription request, including a moderate (~25-bit) stamp.
as it should be for a normal camram interaction
2. server decides how much postage to charge and sends a challenge with a
minimal (10-bit or something) stamp indicating return postage. It logs
the required postage in addition to the recipient and the challenge hash.
don't think of it as a challenge as much as a postage due response.
Yes, it is a challenge to be satisfied but it is something that should
If you give less than the postage expected by the originating user, you
might as well give no postage at all since it will be treated the same
way. If you don't do that, then you create a hole for spammers to use
lower postage rates.
unfortunately, this requirement keeps the DOS possibilities there
it turns out that the same DOS by postage due notices are present in
this protocol as well. Think joe jobbing.
3. subscriber sends a signed subscription confirmation including a stamp
in the amount of the return postage from step 2.
4. the list permits the signing keyid to post messages. It sends a
"welcome to the list" message with a return postage for posting to the
list (the previous one was a much larger requirement meant to discourage
If a list is being abused, increase one or both postage rates a couple
bits for a few days. When the spammer tires of paying high electric
bills, lower the rates to normal.
interesting protocol. I'm not sure it's going to save us from denial of
service attacks because it only changes where/how the attack can be
launched. I think this is an interesting aspect of using proof of work
stamps. There is a symmetry of how you can launch attacks on systems or
from systems with and without proof of work stamps. The important thing
about a stamp system is that you may be able to trigger an attack but
you limit the rate at which you can attack by the very nature of the
resource consumption aspect of proof of work stamps.
Using anything except pgp or s/mime seems like a huge barrier to adoption.
Only camram users could sign using ecc, so only camram users could ever be
whitelisted (until someone wrote a standalone ecc client).
not necessarily. It would be something that would work, a publicly
available etc. the barriers to to adoption would be mostly laziness and
NIH of which the universe has an infinite supply.
People don't ordinarily attach keys to email, so requiring keys to be sent
during initial communication, very few non-camram users would be
whitelisted. If camram parsed X-...-Fingerprint: headers and tried to
grab those keys from keyservers, that might accelerate camram's
usefulness. That header is just a sha1 hash
of the key with some inserted whitespace.
actually, we white list every user we speak with although unfortunately,
they are white list by name. Using the keys and making something about
them publicly visible will raise visibility that users can do something
on their own. It would be better if we had a version of camram running
on a PC but I need to has some volunteers or make more money before I
can afford to do that
If that fails, and if there's no attached keyblock, camram could
autorespond telling the sender to include the key fingerprint or keyblock
if they want to be whitelisted. Or in the interest of simplicity it could
do nothing, delivering the message but not whitelisting the sender.
it's possible one might be able to send the key block only after you
have received a stamped piece of e-mail from someone. And then go into
the stand to key transition protocol.
As you've pointed out, there's no reason to send keys if there's no one
dared to receive them and it's OK to let the user generates stamps a few
more times before making the transition to a signature based environment.
hmmm. I do think that would work rather well. That might also be a good
trigger for destroying an existing key based relationship. That is, if
you receive this piece of e-mail with a stamp from someone you know, you
destroy their key in your white list and go back to the start of the
protocol. Yes, that is a man in the middle vulnerability but you can
fix that by putting extra safeguards on key management if that is
something you really want. For ordinary users, it doesn't matter.
Other related posts: