Any pointers to designing "vouchers"?
Ian Sparkes
"vouchers"? I'm thinking here of a serial number that can be redeemed for
something such as a discount or a software registration? Freedom does this
when you buy tokens for Nyms - you get a Serial number back that you can
later redeem for five Nym-Years.
I've been playing with simple obfuscation and hash collisions, but what
I've come up with doesn't make me feel all that confident at the moment.
Any pointers or ideas would be greatly appreciated.
st...@accessdata.com
protocol. If not, a signed message will do just fine.
--
Mike Stay
Programmer / Crypto guy
AccessData Corp.
mailto:st...@accessdata.com
Adam Shostack
We send out a somewhat structured coin, with embedded codes to tell us
what value the coin has. We have a list of valid coins, and a list of
spent coins stored on the system that turns coins into nyms. (The
lists are actually lists of hashes of the coins, to make accidental
correlations hard.
Depending on what its for, you may be able to get by with a (value,
nonce, authenticator) tuple, and store lists of spent tuples.
Its really not a very hard problem if you don't care about anonymity,
and if you do, its not a hard problem either, there are just patents
in the way. We use a business process to get someplace in the
middle.
Adam
--
Tired of co-workers slowing you down? Leave them behind.
http://jobs.zeroknowledge.com
Pete Chown
> Does anyone have any pointers to the design of schemes to create
> "vouchers"?
What sort of a voucher? If it will be issued and redeemed at the same
organisation, and anonymity isn't important, you could just use a big
random number. You would then store a list of outstanding vouchers.
Alternatively you could have a signed message; with a MAC if you just
want to be able to recognise it yourself, or a secret key signature if
you want everyone to be able to check validity. You would have to
store redeemed vouchers to prevent replay. This means that you should
probably have an expiry date as well so that eventually you can throw
them away.
If you do want anonymity, some of the Chaum schemes would work as
vouchers...
----------------------------------------------------------------------
phone +44 (0) 20 8542 7856, fax +44 (0) 20 8543 0176, post:
Skygate Technology Ltd, 8 Lombard Road, Wimbledon, London, SW19 3TZ
Anonymous
> Does anyone have any pointers to the design of schemes to create
> "vouchers"? I'm thinking here of a serial number that can be redeemed for
> something such as a discount or a software registration? Freedom does this
> when you buy tokens for Nyms - you get a Serial number back that you can
> later redeem for five Nym-Years.
>
> I've been playing with simple obfuscation and hash collisions, but what
> I've come up with doesn't make me feel all that confident at the moment.
A voucher can be as simple as a number which the issuer keeps a copy of
on an internal list, then removes it from the list when it is presented
for redemption. It could be a random number large enough to prevent
people guessing a value which would match one on the list.
If the issuer doesn't want to keep a list, it can make the vouchers
be the encryption under a secret 3DES key of a simple serial number.
Then at redemption time it decrypts the value using its secret key and
makes sure it has a simple format. Alternatively it could use a public
key signature system and sign serial numbers. These schemes work best
if there is no problem with double-redemption, otherwise the server has
to keep a list of redeemed vouchers and you don't gain much over the
first method.
You might be asking about blind vouchers, where the redemption can't be
linked up with the issuance. This is basically the same as electronic
cash tokens, and the recent discussions on David Wagner's blinding scheme
as used in the Lucre cash system may be relevant.
murtin...@gmail.com
discount voucher. I usually use it. It always has cheap vouchers for every product.