Problem with some digicash applications

[wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)]

One security hole in online digicash systems of the Chaum variety is
that you _do_ need to make sure the money is only transmitted in
encrypted forms not susceptible to playback attacks.
(I haven't read the magic-money code yet...)
The threat scenarios look like this:
             cash                cash
Alice--------------------->Bob---fast_net-----slow_net--------->Bank
         \                       \                      /
          \_______________________\___Eve_____________/

If Eve can read the cash either before Bob gets it or before Bob's
message gets from his fast LAN across the slow part of the net
to the bank, then she can occasionally spend it before Bob can.
(This is especially likely if she's Bob's favorite remailer
or network provider.)  (On-line validation through slow remailers???)

It's probably not much of a problem for radio-tollbooths,
since the tollbooth(=Bob=bank) gets it as fast as Eve does.
It's also not a problem if Eve can't find the cash part of a message
between Alice and Bob or Bob and the bank.  
Unencrypted messages might let Eve subsitute her bank account for Bob's.

But consider fixed-format messages of the form:
	RSA(Key), IDEACBC[Key](Cash,Account#)
which might be commonly used by a Teller Machine or the digicash
equivalent of a credit card authorization box.
If Eve stomps on the Account-number bits, even though she can't
break the encryption to substitute her account number for Bob's,
she can substitute a random account number for Bob's.
This acts as a denial-of-service attack against Bob.

As a defense, either the message has to contain signatures or at least
MACs for validation, and be rejected if invalid, or the format
needs to make it impossible to find the account number field
or to modify it without trashing the cash as well.

A solution that's probably _not_ acceptible is for the Bank
to return a message of the form
	Sign[Bank](OK,Cash,Account#)
since this reveals the account number, which loses some privacy.
It maybe ok to use a hash of the account number, or a nonce + the
account number encrypted with the account-owner's public key.
# Bill Stewart  AT&T Global Information Solutions, aka NCR Corp
# 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204
# email bill.stewart@pleasantonca.ncr.com billstewart@attmail.com
# ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465