Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
On 10/25/05, Travis H. [EMAIL PROTECTED] wrote: More on topic, I recently heard about a scam involving differential reversibility between two remote payment systems. The fraudster sends you an email asking you to make a Western Union payment to a third party, and deposits the requested amount plus a bonus for you using paypal. The victim makes the irreversible payment using Western Union, and later finds out the credit card used to make the paypal payment was stolen when paypal reverses the transaction, leaving the victim short. This is why you can't buy ecash with your credit card. Too easy to reverse the transaction, and by then the ecash has been blinded away. If paypal can be reversed just as easily that won't work either. This illustrates a general problem with these irreversible payment schemes, it is very hard to simply acquire the currency. Any time you go from a reversible payment system (as all the popular ones are) to an irreversible one you have an impedence mismatch and the transfer reflects rather than going through (so to speak). CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
One other point with regard to Daniel Nagy's paper at http://www.epointsystem.org/~nagydani/ICETE2005.pdf A good way to organize papers like this is to first present the desired properties of systems like yours (and optionally show that other systems fail to meet one or more of these properties); then to present your system; and finally to go back through and show how your system meets each of the properties, perhaps better than any others. This paper is lacking that last step. It would be helpful to see the epoint system evaluated with regard to each of the listed properties. In particular I have concerns about the finality and irreversibility of payments, given that the issuer keeps track of each token as it progresses through the system. Whenever one token is exchanged for a new one, the issuer records and publishes the linkage between the new token and the old one. This public record is what lets people know that the issuer is not forging tokens at will, but it does let the issuer, and possibly others, track payments as they flow through the system. This could be grounds for reversibility in some cases, although the details depend on how the system is implemented. It would be good to see a critical analysis of how epoints would maintain irreversibility, as part of the paper. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
On 10/28/05, Daniel A. Nagy [EMAIL PROTECTED] wrote: Irreversibility of transactions hinges on two features of the proposed systetm: the fundamentally irreversible nature of publishing information in the public records and the fact that in order to invalidate a secret, one needs to know it; the issuer does not learn the secret at all in some implementnations and only learns it when it is spent in others. In both cases, reversal is impossible, albeit for different reasons. Let's say, Alice made a payment to Bob, and Ivan wishes to reverse it with the possible cooperation of Alice, but definitely without Bob's help. Alice's secret is Da, Bob's secret is Db, the corresponding challenges are, respectively, Ca and Cb, and the S message containing the exchange request Da-Cb has already been published. In the first case, when the secret is not revealed, there is simply no way to express reverslas. There is no S message with suitable semantics semantics, making it impossible to invalidate Db if Bob refuses to reveal it. The issuer can still invalidate it even though you have not explicitly defined such an operation. If Alice paid Bob and then convinces the issuer that Bob cheated her, the issuer could refuse to honor the Db deposit or exchange operation. From the recipient's perspective, his cash is at risk at least until he has spent it or exchanged it out of the system. The fact that you don't have an issuer invalidates cash operation in your system doesn't mean it couldn't happen. Alice could get a court order forcing the issuer to do this. The point is that reversal is technically possible, and you can't define it away just by saying that the issuer won't do that. If the issuer has the power to reverse transactions, the system does not have full ireversibility, even though the issuer hopes never to exercise his power. In the second case, Db is revealed when Bob tries to spend it, so Ivan can, in principle, steal (confiscate) it, instead of processing, but at that point Da has already been revealed to the public and Alice has no means to prove that she was in excusive possession of Da before it became public information. That is an interesting possibility, but I can think of a way around it. Alice could embed a secret within her secret. She could base part of her secret on a hash of an even-more-secret value which she would not reveal when spending/exchanging. Then if it came to where she had to prove that she was the proper beneficiary of a reversed transaction, she could reveal the inner secret to justify her claim. Now, one can extend the list of possible S messages to allow for reversals in the first scenario, but even in that case Ivan cannot hide the fact of reversal from the public after it happened and the fact that he is prepared to reverse payments even before he actually does so, because the users and auditors need to know the syntax and the semantics of the additional S messages in order to be able to use Ivan's services. That's true, the public visibility of the system makes secret reversals impossible. That's very good - one of the problems with e-gold was that it was never clear when they were reversing and freezing accounts. Visibility is a great feature. But it doesn't keep reversals from happening, and it still leaves doubt about how final transactions will be in this system. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
If you have to be that confident in your computer security to use the payment system, it's not going to have many clients. Maybe the trusted computing platform (palladium) may have something to offer after all, namely enabling naive users to use services that require confidence in their own security. One could argue it's like going to a Vegas casino; software vendors (MS *cough* MS) probably won't cheat you in such a system because they don't have to; the odds are in their favor already. The whole system is designed to assure they get paid, and they have a lot to lose (confidence in the platform) by cheating you (at least in ways that can be detected). And since you won't be able to do anything to compromise the security, you can't screw it up. While I wouldn't see an advantage in that, I might recommend it for my grandmother. More on topic, I recently heard about a scam involving differential reversibility between two remote payment systems. The fraudster sends you an email asking you to make a Western Union payment to a third party, and deposits the requested amount plus a bonus for you using paypal. The victim makes the irreversible payment using Western Union, and later finds out the credit card used to make the paypal payment was stolen when paypal reverses the transaction, leaving the victim short. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
On 10/22/05, Ian G [EMAIL PROTECTED] wrote: R. Hirschfeld wrote: This is not strictly correct. The payer can reveal the blinding factor, making the payment traceable. I believe Chaum deliberately chose for one-way untraceability (untraceable by the payee but not by the payer) in order to address concerns such as blackmailing, extortion, etc. The protocol can be modified to make it fully untraceable, but that's not how it is designed. Huh - first I've heard of that, would be encouraging if that worked. How does it handle an intermediary fall guy? Say Bad Guy Bob extorts Alice, and organises the payoff to Freddy Fall Guy. This would mean that Alice can strip her blinding factors and reveal that she paid to Freddy, but as Freddy is not to be found, he can't be encouraged to reveal his blinding factors so as to reveal that Bob bolted with the dosh. Right, that is one of the kinds of modifications that Ray referred to. If the mint allows (de-facto) anonymous exchanges then a blackmailer can simply do an exchange of his ecash before spending it and he will be home free. Another mod is for the blackmailer to supply the proto-coin to be signed, in blinded form. One property of Daniel Nagy's epoint system is that it creates chains where each token that gets created is linked to the one it came from. This could be sold as an anti-abuse feature, that blackmailers and extortionists would have a harder time avoiding being caught. In general it is an anti-laundering feature since you can't wash your money clean, it always links back to when it was dirty. U.S. law generally requires that stolen goods be returned to the original owner without compensation to the current holder, even if they had been purchased legitimately (from the thief or his agent) by an innocent third party. Likewise a payment system with traceable money might find itself subject to legal orders to reverse subsequent transactions, confiscate value held by third parties and return the ill-gotten gains to the victim of theft or fraud. Depending on the full operational details of the system, Daniel Nagy's epoints might be vulnerable to such legal actions. Note that e-gold, which originally sold non-reversibility as a key benefit of the system, found that this feature attracted Ponzi schemes and fraudsters of all stripes, and eventually it was forced to reverse transactions and freeze accounts. It's not clear that any payment system which keeps information around to allow for potential reversibility can avoid eventually succumbing to pressure to reverse transactions. Only a Chaumian type system, whose technology makes reversibility fundamentally impossible, is guaranteed to allow for final clearing. And even then, it might just be that the operators themselves will be targeted for liability since they have engineered a system that makes it impossible to go after the fruits of criminal actions. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
On 10/24/05, Steve Schear [EMAIL PROTECTED] wrote: I don't think E-gold ever held out its system as non-reversible with proper court order. All reverses I am aware happened either due to some technical problem with their system or an order from a court of competence in the matter at hand. Back in the days of such companies as emutualfun.com and stockgeneration.com there were cases where e-gold froze accounts without waiting for court orders. I was involved with the discussion on the e-gold mailing lists back then and it caused considerable hard feeling among the users. E-gold was struggling to deal with the onslaught of criminal activity (Ian Grigg described the prevailing mood as one of 'angst') and they were thrown into a reactive mode. Eventually I think they got their house in order and established policies that were more reasonable. Its not clear at all that courts will find engineering a system for irreversibility is illegal or contributory if there was good justification for legal business purposes, which of course there are. Yes, but unfortunately it is not clear at all that courts would find the opposite, either. If a lawsuit names the currency issuer as a defendant, which it almost certainly would, a judge might order the issuer's finances frozen or impose other measures which would impair its business survival while trying to sort out who is at fault. It would take someone with real cojones to go forward with a business venture of this type in such uncharted waters. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
On 10/24/05, John Kelsey [EMAIL PROTECTED] wrote: More to the point, an irreversible payment system raises big practical problems in a world full of very hard-to-secure PCs running the relevant software. One exploitable software bug, properly used, can steal an enormous amount of money in an irreversible way. And if your goal is to sow chaos, you don't even need to put most of the stolen money in your own account--just randomly move it around in irreversible, untraceable ways, making sure that your accounts are among the ones that benefit from the random generosity of the attack. To clarify one point, it is not necessary to have accounts in an ecash system. Probably the simpler approach is for a mint that has three basic functions: selling ecash for real money; exchanging ecash for new ecash of equal value; and buying ecash for real money. All ecash exchanges with the mint can be anonymous, and only when ecash is exchanged for real money does that side of the transaction require a bank account number or similar identifying information. In such a system, the ecash resides not in accounts, but in digital wallets which are held in files on end users' computers. The basic attack scenario then is some kind of virus which hunts for such files and sends the ecash to the perpetrator. If the ecash wallet is protected, by a password or perhaps a token which must be inserted, the virus can lie in wait and grab the ecash once the user opens the wallet manually. There are several kinds of malicious activities that are possible, from simply deleting the cash to broadcasting it in encrypted form such as by IRC. Perhaps it could even engage in the quixotic action of redistributing some of the cash among the users, but my guess is that pecuniary motivations would dominate and most viruses will simply do their best to steal ecash. Without accounts per se, and using a broadcast channel, there is little danger in receiving or spending the stolen money. Digital wallets will require real security in user PCs. Still I don't see why we don't already have this problem with online banking and similar financial services. Couldn't a virus today steal people's passwords and command their banks to transfer funds, just as easily as the fraud described above? To the extent that this is not happening, the threat against ecash may not happen either. The payment system operators will surely be sued for this, because they're the only ones who will be reachable. They will go broke, and the users will be out their money, and nobody will be silly enough to make their mistake again. They might be sued but they won't necessarily go broke. It depends on how deep the pockets are suing them compared to their own, and most especially it depends on whether they win or lose the lawsuit. As Steve Schear noted, there is a reasonable argument that a payment system issuer should not be held liable for the misdeeds of its customers. Jurisdictional issues may be important as well. Clearly anyone proposing to enter this business will have to accept the risk and cost of defending against such lawsuits as part of the business plan. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
From: cyphrpunk [EMAIL PROTECTED] Sent: Oct 24, 2005 5:58 PM To: John Kelsey [EMAIL PROTECTED] Subject: Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems ... Digital wallets will require real security in user PCs. Still I don't see why we don't already have this problem with online banking and similar financial services. Couldn't a virus today steal people's passwords and command their banks to transfer funds, just as easily as the fraud described above? To the extent that this is not happening, the threat against ecash may not happen either. Well, one difference is that those transactions can often be undone, if imperfectly at times. The whole set of transactions is logged in many different places, and if there's an attack, there's some reasonable hope of getting the money back. And that said, there have been reports of spyware stealing passwords for online banking systems, and of course, there are tons of phishing and pharming schemes to get the account passwords in a more straightforward way. The point is, if you're ripped off in this way, there's a reasonable chance you can get your money back, because the bank has a complete record of the transactions that were done. There's no chance of this happening when there's no record of the transaction anywhere. The payment system operators will surely be sued for this, because they're the only ones who will be reachable. They will go broke, and the users will be out their money, and nobody will be silly enough to make their mistake again. They might be sued but they won't necessarily go broke. It depends on how deep the pockets are suing them compared to their own, and most especially it depends on whether they win or lose the lawsuit. I don't think so. Suppose there's a widespread attack that steals money from tens of thousands of users of this payment technology. There seem to be two choices: a. The payment system somehow makes good on their losses. b. Everyone who isn't dead or insane pulls every dime left in that system out, knowing that they could be next. It's not even clear that these are mutually exclusive, but if (a) doesn't happen, (b) surely will. Nobody wants their money stolen, and I don't think many people are so confident of their computer security that they're willing to bet huge amounts of money on it. If you have to be that confident in your computer security to use the payment system, it's not going to have many clients. CP --John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
R. Hirschfeld wrote: Date: Thu, 20 Oct 2005 11:31:39 -0700 From: cyphrpunk [EMAIL PROTECTED] 2. Cash payments are final. After the fact, the paying party has no means to reverse the payment. We call this property of cash transactions _irreversibility_. Certainly Chaum ecash has this property. Because deposits are unlinkable to withdrawals, there is no way even in principle to reverse a transaction. This is not strictly correct. The payer can reveal the blinding factor, making the payment traceable. I believe Chaum deliberately chose for one-way untraceability (untraceable by the payee but not by the payer) in order to address concerns such as blackmailing, extortion, etc. The protocol can be modified to make it fully untraceable, but that's not how it is designed. Huh - first I've heard of that, would be encouraging if that worked. How does it handle an intermediary fall guy? Say Bad Guy Bob extorts Alice, and organises the payoff to Freddy Fall Guy. This would mean that Alice can strip her blinding factors and reveal that she paid to Freddy, but as Freddy is not to be found, he can't be encouraged to reveal his blinding factors so as to reveal that Bob bolted with the dosh. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
As far as the issue of receipts in Chaumian ecash, there have been a couple of approaches discussed. The simplest goes like this. If Alice will pay Bob, Bob supplies Alice with a blinded proto-coin, along with a signed statement, I will perform service X if Alice supplies me with a mint signature on this value Y. Alice pays to get the blinded proto-coin Y signed by the mint. Now she can give it to Bob and show the signature on Y in the future to prove that she upheld her end. A slightly more complicated one starts again with Bob supplying Alice with a blinded proto-coin, which Alice signs. Now she and Bob do a simultaneous exchange of secrets protocol to exchange their two signatures. This can be done for example using the commitment scheme of Damgard from Eurocrypt 93. Bob gets the signature necessary to create his coin, and Alice gets the signed receipt (or even better, perhaps Bob's signature could even constitute the service Alice is buying). I would be very interested to hear about a practical application which combines the need for non-reversibility (which requires a degree of anonymity) with the need to be able to prove that payment was made (which seems to imply access to a legal system to force performance, an institution which generally will require identification). CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
On Thu, 20 Oct 2005, cyphrpunk wrote: system without excessive complications. Only the fifth point, the ability for outsiders to monitor the amount of cash in circulation, is not satisfied. But even then, the ecash mint software, and procedures and controls followed by the issuer, could be designed to allow third party audits similarly to how paper money cash issuers might be audited today. One approach, investigated by Hal Finney, is to run the mint on a platform that allows remote attestation. Check out rpow.net - he has a working implementation of a proof of work payment system hosted on an IBM 4758. -David Molnar - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
