On Fri, Mar 21, 2003 at 02:28:31PM -0600, Scott A Crosby wrote:
On Fri, 21 Mar 2003 19:46:08 +0000, Adam Back
<adam(_at_)cypherspace(_dot_)org> writes:
The Stamps discussion seems to be reinventing hashcash (are some not
aware of hashcash, or is there some aspect of the Stamps discussion
different from hashcash in some way I am not seeing?)
Yes, it is strongly inspired by HashCash, but it is different. The
differences is that HashCash is only used for initial communication.
This is an optimization also proposed for hashcash when one gets down
to "so how would you deploy this" question. See for example the
CAMRAM architecture:
http://www.camram.org
In my system, almost all stamps are really one-time-use random nonces
generated by the recipient. The stamps are automatically attached to
all outgoing messages, but may be obtained by solving a CAPTCHA or
other out-of-band means. This means the HashCash stamps are relegated
to only being used for the initial message in a communication.
Thus, I can afford to make the hashcash stamps incredibly expensive,
on the order of tens of minutes, because few messages ever use them.
ditto see CAMRAM. I had proposed a token sent from the recipient to
the sender attached to any message which could be re-used by the
sender to send replies in the vein of Lucent's LPWA (Lucent
Personalized Web Assistant) target revokable email address:
http://www.bell-labs.com/project/lpwa/proxy_index.html
In particular I proposed such a token would be a MAC computed using a
secret key held by the user. Then he could verify it without storage,
based just on the sender address and the token. Having expiry could
be optional feature, but there is limited need given the storage-less
aspect. Tokens could be revoked by putting them in a recipient local
black-list.
CAMRAM settled on using signatures for the tokens in place of a
MAC-based token but it's effectively the same idea I think.
CAMRAM also proposed allowing turing proofs in place of tokens
(CAPTCHA is one example of a turing proof).
An additional idea previously proposed was that reducing the use of
hashcash tokens to first unsolicited email could perhaps be used
instead of increasing practical hashcash cost, could be used to deploy
hashcash token creation into the senders sending mail hub. This would
then remove the need for a hashcash aware client. The downside is it
increases sending MTA load, but the deployment problem is easier for
MTAs than for clients.
Adam
Since so few are used, I consider it acceptable to require the
recipient to maintain a database of all of them ever used. The lack of
datestamps allows a MUA to precompute stamps ahead-of-time based on
for addresses in the address book.
Also, since MUA's may mint arbitrary stamps and bulk mailers may send
a control message requesting the same, bulk emailers do not require
users to implement an exception mechanism.
all of the options discussed so far in this thread are documented, or
improved upon in that paper.
I ruthlessly simplified Hashcash to suit the limited situation I am
using it for.
where you can visually see the leading 33 bits of 0s.
Nice change.
Scott
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg