[hashcash] Re: hashcash v1 questions

Justin wrote: 
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


---- 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

....

Ya well, I never said I was a jingle writer either. I'm a far better satirist.

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 technique 

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 be automatic.

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
spammer subscription).

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.

---eric



Other related posts: