[hashcash] Re: Opportunistic signatures - a proposed design

Atom 'Smasher' wrote:
if one is using pgp on windoze, then i agree with that analogy. 

hey, I resemble that remark...

i would also agree that pgp signatures, with 1024+ bit keys is complete and total overkill *if* it's being used an an anti-spam measure... but if it's being used for other reasons, and it just so happens to be useful in bypassing a spam filter, then that's a different story. i think that conventional asymmetric keys in the 256-512 bit range would be adequate for the purpose of automatically signing an email, *if* the intended purpose is to bypass a filter, *not* to prove authorship. HOWEVER, the more i think about that type of system, the more i like hashcash better. 

and we come around the barn yet again.

Hashcash is wonderful for lots of things. Unfortunately, it really really sucks for mailing lists because mailing lists are behaviorally just like spammers (lots of mail in a short period of time).

It's also unreasonable to impose the hashcash burden when communicating to someone you know.

To get large-scale acceptance, we'll need an approach that meets enterprise needs. Most enterprises will not touch a solution that requires large-scale desktop modification. The support burden is just too high. Therefore, we'll need a solution that can be implemented by a "drop-in box". Which is difficult because enterprise e-mail looks just like a spammer for the same reason that mailing lists do.

So, if there is a different solution that lets us create "exemptions" to the hashcash load without giving any advantage to spammers, I would like to hear about it. Personally, I believe that some form of public key solution is the right one.

I believe this because it's a well understood technology with manageable risk factors. Taken further than signatures, it increases overall confidentiality of communications without requiring any user involvement.

So, I ask that if there is no better alternative that we try to create a prototype implementation. Just experiment with it and see how it works.

we would need to functions/commands. Signing/encrypting which takes sender and recipient keys, message then yields signed/encrypted message. The converse takes sender and recipient keys, signed/encrypted message then yields plaintext message.

How difficult is that? (Actually, pretty dam difficult as my past experience shows since pgp/gpg insists on managing its own key ring)

In any case, that is the model.  Can it be done?

---eric

Other related posts: