On Wed, Dec 3, 2008 at 1:26 PM, John Levine <johnl(_at_)taugh(_dot_)com> wrote:
All the sender does is present his identity. The recipient's postage
meter issues a stamp which is only good for sending one message to that
recipient. The sender's "coin" has to come from a bank trusted by the
recipient [...]
But can we please stop arguing from the assumption that senders can
arbitrarily print and re-use one stamp for many recipients?
In the scenario above, what happens when a sender buys one coin and
simultaneously presents it to 1000 recipients?
On a practical level, his bank receives complaints from a small percentage
of the 999 potential fraud victims and revokes his account.
On a technical level, those 999 recipients immediately recognize, without
any
3rd party verification to the bank, that the "coin" was not wrapped in their
"stamp",
and they reject it. Only the one recipient who recieved the initial
presentation
of identity step ("request for stamp") accepts the message, opens the coin,
and presents it to the bank for redemption.
To take your question a step further. Assume that the perpetrator
buys one valid coin and presents identity to 1000 recipients asking
each for a "stamp". He then wraps a copy of the coin in each of
the 1000 recipient stamps. Each of the 1000 recipients recognize
a coin wrapped in their own stamp and opens the coin and attempts
to redeem it with the bank, which only redeems the first such coin,
but is alerted to attempted fraud and revokes the sender's account.
Recipients would automate feedback of coin rejection into their
stamp generator by monitoring their bank's account rejection watchlist,
which might be an RSS feed or a specialized type of DNSBL. In any
case, there is crypto identity in the coin, and timing built into
the recipient's stamp generator. The vulnerability timeframe for recipients
is how long it takes for two of the same coins to show up at the bank
and for the bank to get an alert into the feedback loop so that other stamp
generators start refusing the requesting identity back at Step 1.
Gerald
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg