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