mathew wrote:
On Sun, Feb 15, 2009 at 17:12, John Levine <johnl(_at_)taugh(_dot_)com
<mailto:johnl(_at_)taugh(_dot_)com>> wrote:
>> It is possible to defend against this threat, but not cheaply,
since
>> the defense requires a robust transaction system that can serialize
>> the thousand requests, approve one, and reject the other 999, while
>> still providing service to the rest of their customers.
>Nonsense. You just make the purchased stamp dependent upon the
address of
>the recipient, for example by hashing the To: address inside the
>cryptographic stamp when it's minted.
Aw, come on. Please don't tell me I have to explain why this
model has
the exact same problem.
Go on, indulge us. Explain why stamps that are hashed to the recipient
can still be spent on multiple spams unless a network transaction is
carried out for every one.
Let's go ahead and assume that the stamp also has an expiry date
encoded into it, mmkay?
mathew
I think we need to go the other way. Stop assuming the token contains
*anything* useful.
It is intended to be an opaque meaningless value. This removes the
possibility of anything
but brute-force forgery.
If we have lots of complex encoding of values we open the door for
people to forge those
values. We also extend the time to clear a token through the receiving
"bank" considerably
and enter a world of crypto-library incompatibility, varying format
versions etc.
Before I get flamed I should say that a well designed DHT lookup for an
opaque token would
certainly be faster than verifying a signature then doing a DHT lookup
for the serial number.
I will also go out on a limb and say that doing a DHT insert of random
block of pre-existing
random data and monitoring the result for duplication will be faster
than marshaling and signing
a new token based on a series of values.
This is not to say that the "BANK" can't encode something they find
useful in a token, but
I would urge them not to. "BANKS" are also welcome to declare
number-space limitations
if the like e.g. mod 7 or prime but again this severely limits the
search-space for a brute-force
attack.
The beauty of a simple token like this is that you can keep a cache of
token's you have seen
recently. Recently being defined by the amount of disk space you wish to
dedicate to this.
If you have seen the token in the last "X" consider it invalid. MTA
implementations need
to be vigilant in looking for brute-force attacks (as should "BANKS") to
prevent cache-poisoning
attacks.
Thanks
Ben
------------------------------------------------------------------------
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg