On 2004-05-31T15:41:25-0400, Eric S. Johansson wrote: > >If camram puts keys in headers, I'll probably pull them out and import > >them if the message has sufficient postage. And while I can understand > >why camram might put keys in headers, I don't think headers are a > >reasonable place to put 700-byte base64-encoded strings. I'm not at all > >happy about the prospect of those 700-byte strings being in _hashcash_ > >headers. > > OK, give me an alternative key propagation method that: > > 1) operates completely peer-to-peer > 2) requires no user involvement 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. I haven't tested this snippet (I think the escaping may be wrong), but it should work in concept: if ($HASH_BITS > 27 && /X-(GPG|PGP)-Fingerprint: !.*/) `HASH=\`echo $MATCH2 | sed -e "s/ \\+//"\`; gpg --quiet --batch --recv-keys \$HASH` procmail users can do nearly the same thing using \/ 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. > 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. 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. 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. 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. > one thought that comes to mind is to try and use elliptical curve > techniques because, if memory serves, the keys are smaller for the same > strength. 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). 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. 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. -- "Not your decision to make." "Yes. But it's the right decision, and I made it for my daughter." - Bill, Beatrix; Kill Bill Vol. 2