The Lucre e-cash implementation is not secure

[amiller]

1. Lucre is an unnecessarily complicated protocol. It was originally written to avoid infringing Chaum's e-cash patents. This patent has since expired and there's no particular need for Lucre anymore.
2. The Lucre protocol is vulnerable to deanonymization attacks, described in the Lucre whitepaper http://anoncvs.aldigital.co.uk/lucre/theory2.pdf The server can sign its messages to Alice with a watermarked key that allows it to recognize when Alice spends her coin. Countermeasures to this are described in the whitepaper, but they are imperfect, add more complexity, and are not included in the current implementation.
3. Even if original Chaumian e-cash were used, or the Lucre countermeasures were implemented, the e-cash protocol would still be vulnerable to the server undetectably forging coins.

A better solution would be to replace the Lucre e-cash protocol with an auditable E-Cash protocol, such as the one used in Zerocoin.
http://link.springer.com/chapter/10.1007/3-540-45472-1_5
http://zerocoin.org/media/pdf/ZerocoinOakland.pdf

[amiller]

More supporting details:

• This mailing list discussion from 2002 describes of the goals in Lucre:
  http://www.metzdowd.com/pipermail/cryptography/2002-August/003001.html
• Regarding point 1... I actually have no idea how to confirm whether Chaum's e-cash patent has expired. Here's the patent I think covers it:
  http://assignments.uspto.gov/assignments/q?db=pat&pat=4947430

[lclc]

Thanks a lot! After we restructured and decoupled the OT source code we will look into this.

[FellowTraveler]

1: Amiller is correct that Lucre was written to get around Chaum's patents, as well as the fact that the patent has since expired.

He's also correct that there's no particular need for Lucre anymore -- except for the fact that it's the only cash algorithm in OT. Once we add another cash algorithm we can talk about removing Lucre.

2: Re: de-anonymization attacks. If the server gives one user a different mint file than was given to all the other users, then it becomes possible to trace the cash withdrawn by that user. The solution is to distribute the mint file in a public channel so all users download it from the same place. Alternately the clients could just compare notes on the mint file hash, to make sure they are all using the same one.

I believe this same attack is possible with other cash algorithms, it's not specific to Lucre. For example, if we used Chaum instead, and gave a different mint file to one user than we gave the other users, the same attack would be possible with Chaum.

3: "the e-cash protocol would still be vulnerable to the server undetectably forging coins."

If you have a server that ONLY issues digital cash tokens, then you must trust that server, and as Amiller says, the server has the power to inflate the coins.

However, it is not so simple in OT, which mitigates this quite a bit. In OT, when you withdraw cash, the funds are moved from your account into the server's cash reserve account, before the coins are issued to you. Then when Bob deposits the coins, the funds are then moved from the cash reserve account into Bob's account.

So even if the server issues inflated coins, a recipient cannot REDEEM those coins without pulling funds from the cash reserve account. And once the cash reserve account goes to a 0 balance, then deposits will start to fail. This could result in a failed audit, thus kicking the fraudulent server out of the voting pool. This means even if the server inflates coins, they still cannot be REDEEMED in a greater amount than the amount of legitimate withdrawals.

If an evil server wants to avoid this, he would have to add the corresponding funds to the cash reserve account, whenever inflating coins. (But of course this would also cause a failed audit.)

Therefore I think the server could inflate a small number of coins (it would have to be a small percentage of the amount in the cash reserve account) but any more, and he will fail an audit.

This is "pretty good" security for the cash, and as I said, would most likely be the same situation for any other cash algorithm, not just Lucre.

However, if there are even better algorithms, that sounds great too. Waiting on a pull request from Amiller.

[ayoubmtd]

Isn't the use of Diffie-Hellman scheme makes the keys shorter which means better for mobile payment ?