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
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
Re: [PracticalSecurity] Anonymity - great technology but hardly used
On 10/26/05, Shawn K. Quinn [EMAIL PROTECTED] wrote: On Tue, 2005-10-25 at 23:40 -0500, Travis H. wrote: Many of the anonymity protocols require multiple participants, and thus are subject to what economists call network externalities. The best example I can think of is Microsoft Office file formats. I don't buy MS Office because it's the best software at creating documents, but I have to buy it because the person in HR insists on making our timecards in Excel format. 1) You have told your HR person what a bad idea it is to introduce a dependency on a proprietary file format, right? This is off-topic. Let's not degenerate into random Microsoft bashing. Keep the focus on anonymity. That's what the cypherpunks list is about. CP
Re: [EMAIL PROTECTED]: Re: [p2p-hackers] P2P Authentication]
From: Kerry Bonin [EMAIL PROTECTED] Date: Thu, 27 Oct 2005 06:52:57 -0700 To: [EMAIL PROTECTED], Peer-to-peer development. [EMAIL PROTECTED] Subject: Re: [p2p-hackers] P2P Authentication User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) Reply-To: Peer-to-peer development. [EMAIL PROTECTED] There are only two good ways to provide man-in-the-middle resistant authentication with key repudiation in a distributed system - using a completely trusted out of band channel to manage everything, or use a PKI. I've used PKI for 100k node systems, it works great if you keep it simple and integrate your CRL mechanism - in a distributed system the pieces are all already there! I think some people are put off by the size and complexity of the libraries involved, which doesn't have to be the case - I've got a complete RSA/DSA X.509 compliant cert based PKI (leveraging LibTomCrypt for crypto primitives) in about 2k lines of C++, 30k object code, works great (I'll open that source as LGPL when I deploy next year...) The only hard part about integrating into a p2p network is securing the CA's, and that's more of a network security problem than a p2p problem... It's great to see this guy showing up yet another of the false dogmas of the crypto hacker community: PKI can't work. According to this view, only old fogies and tight ass bureaucrats believe in certifying keys. All the cool kids know that the best key is a bare key. After all, MITM attacks never really happen, this was just an invented threat designed to force poor college kids into paying hundreds of dollars a year for a verisign certificate. But when we come into the P2P world things look very different. Where MITM would require special positioning in the old net, in a distributed P2P network, everyone's a MITM! Every key has passed through dozens of hands before you get to see it. What are the odds that nobody's fucked with it in all that time? You're going to put that thing in your mouth? I don't think so. Using certificates in a P2P network is like using a condom. It's just common sense. Practice safe cex! CP
Re: [PracticalSecurity] Anonymity - great technology but hardly used
The cypherpunks list is about anything we want it to be. At this stage in the lifecycle (post-nuclear-armageddon-weeds-in-the-rubble), it's more about the crazy bastards who are still here than it is about just about anything else. Fine, I want it to be about crypto and anonymity. You can bash Microsoft anywhere on the net. Where else are you going to talk about this shit? CP
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
Re: [EMAIL PROTECTED]: Skype security evaluation]
Wasn't there a rumor last year that Skype didn't do any encryption padding, it just did a straight exponentiation of the plaintext? Would that be safe, if as the report suggests, the data being encrypted is 128 random bits (and assuming the encryption exponent is considerably bigger than 3)? Seems like it's probably OK. A bit risky perhaps to ride bareback like that but I don't see anything inherently fatal. CP
Re: On Digital Cash-like Payment Systems
On 10/26/05, James A. Donald [EMAIL PROTECTED] wrote: How does one inflate a key? Just make it bigger by adding redundancy and padding, before you encrypt it and store it on your disk. That way the attacker who wants to steal your keyring sees a 4 GB encrypted file which actually holds about a kilobyte of meaningful data. Current trojans can steal files and log passwords, but they're not smart enough to decrypt and decompress before uploading. They'll take hours to snatch the keyfile through the net, and maybe they'll get caught in the act. CP
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
Re: [PracticalSecurity] Anonymity - great technology but hardly used
http://www.hbarel.com/Blog/entry0006.html I believe that for anonymity and pseudonymity technologies to survive they have to be applied to applications that require them by design, rather than to mass-market applications that can also do (cheaper) without. If anonymity mechanisms are deployed just to fulfill the wish of particular users then it may fail, because most users don't have that wish strong enough to pay for fulfilling it. An example for such an application (that requires anonymity by design) could be E-Voting, which, unfortunately, suffers from other difficulties. I am sure there are others, though. The truth is exactly the opposite of what is suggested in this article. The desire for anonymous communication is greater today than ever, but the necessary technology does not exist. For the first time there are tens or hundreds of millions of users who have a strong need and desire for high volume anonymous communications. These are file traders, exchanging images, music, movies, TV shows and other forms of communication. The main threat to this illegal but widely practiced activity is legal action by copyright holders against individual traders. The only effective protection against these threats is the barrier that could be provided by anonymity. An effective, anonymous file sharing network would see rapid adoption and would be the number one driver for widespread use of anonymity. But the technology isn't there. Providing real-time, high-volume, anonymous communications is not possible at the present time. Anyone who has experienced the pitiful performance of a Tor web browsing session will be familiar with the iron self-control and patience necessary to keep from throwing the computer out the window in frustration. Yes, you can share files via Tor, at the expense of reducing transfer rates by multiple orders of magnitude. Not only are there efficiency problems, detailed analysis of the security properties of real time anonymous networks have repeatedly shown that the degree of anonymity possible is very limited against a determined attacker. Careful insertion of packet delays and monitoring of corresponding network reactions allow an attacker to easily trace an encrypted communication through the nodes of the network. Effective real-time anonymity is almost a contradiction in terms. Despite these difficulties, file trading is still the usage area with the greatest potential for widespread adoption of anonymity. File traders are fickle and will gravitate rapidly to a new system if it offers significant benefits. If performance can be improved to at least approximate the transfer rates of non-anonymous networks, while allowing enough security to make the job of the content lawyers harder, that could be enough to give this technology the edge it needs to achieve widespread acceptance. CP
Re: cypherpunks@minder.net closing on 11/1
On 10/13/05, Brian Minder [EMAIL PROTECTED] wrote: The minder.net CDR node will be shutting down on November 1, 2005. This includes the cypherpunks-moderated list. Please adjust your subscriptions accordingly. Gmail would facilitate automating a new cypherpunks-moderated list. Gmail's spam filtering is great and even a regular cypherpunks subscription has almost no spam. Sign up a gmail account and subscribe it only to cypherpunks. Use the POP interface to fetch message from gmail, and redistribute those to the new cypherpunks-moderated list. Subscribers gain the anti spam features of cp-moderated without any manual filtering or moderating necessary. CP
Re: [EMAIL PROTECTED]: Skype security evaluation]
On 10/23/05, Travis H. [EMAIL PROTECTED] wrote:
My understanding of the peer-to-peer key agreement protocol (hereafter
p2pka) is based on section 3.3 and 3.4.2 and is something like this:
A - B: N_ab
B - A: N_ba
B - A: Sign{f(N_ab)}_a
A - B: Sign{f(N_ba)}_b
A - B: Sign{A, K_a}_SKYPE
B - A: Sign{B, K_b}_SKYPE
A - B: Sign{R_a}_a
B - A: Sign{R_b}_b
Session key SK_AB = g(R_a, R_b)
But what you have shown here has no encryption, hence no secrecy.
Surely RSA encryption must be used somewhere along the line. The
report doesn't say anything about the details of how that is done. In
particular, although it mentions RSA signature padding it says nothing
about RSA encryption padding.
Is it possible that Skype doesn't use RSA encryption? Or if they do,
do they do it without using any padding, and is that safe?
CP
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
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
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
On 10/20/05, Daniel A. Nagy [EMAIL PROTECTED] wrote: On Thu, Oct 20, 2005 at 03:36:54PM -0700, cyphrpunk wrote: 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. I like this one, though there might be a problem if Alice does everything, except giving Bob the signed version of Y in the end. I can imagine scenarios where this might be a problem. However, it can be relatively easily solved if the mint publishes every signed proto-coin (instead of being handed to the payer, it goes to the public records, from where the payer can retrieve it). There's no reason not to. Good idea! Even without this, if there is a problem then everything will come out in the dispute resolution phase, where Alice will be forced to reveal the mint's signature. Bob may claim at that time never to have seen it before, while Alice may claim that she had sent it earlier, but once they get this far both sides will be forced to agree that Bob has now been paid so the contract can be completed. So this method would be OK for contracts where timeliness is not an important issue. But your idea of having the mint publish its signatures could help even more. 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). This one requires additional infrastructure which needs to be rolled out, which is expensive. Simultaneous exchange of secrets is an elegant cryptographic feat, but the required tools are not available to the general public right now and the motivation to obtain them are insufficient. Thus, a system relying on this cannot be phased in cheaply. I'm not sure what costs you see here. There are two main technologies I am familiar with for signature (or general secret) exchange. One is purely local and involves bit by bit release of the signatures. Both parties first commit to their signatures and use ZK proofs to show that the committed values are in fact signatures over the required data. They then release their sigs a bit at a time, taking turns. If one party aborts prematurely he has at most a factor of 2 advantage over the other in a brute force search to find the missing bits of the signature. While this takes many rounds, it is still pretty fast. Of course the users don't manually initiate each round, it all happens automatically under control of the software. I saw some code to implement this a couple of years ago somewhere on Sourceforge. It actually exchanged PGP signatures, of all things. It does not take any new infrastructure. The other technology is so-called optimistic exchange, where the signatures are provably encrypted to the public key of a trusted third party. The two parties each exchange such encryptions and prove they are valid. Then they exchange the actual signatures in the straighforward manner. If one party does not send his sig, the other can go to the TTP and get it. Since this option exists, there is no incentive for the parties not to complete the transaction and hence the TTP will in practice almost never be used. This one does require the TTP to exist and his public key to be available, but that should be no more new infrastructure than is required for the cash issuer and his key to be distributed. In fact the issuer could be the TTP for dispute resolution if desired. The desirability of a payment vehicle depends on the assortment of goods and services available for it. Now, the lack of non-reversibility might be either a show-stopper or a significant additional cost in the case of some goods and services, while receipts are required in the case of others. Both might be required for transactions in the $100 ... $1000 range between a power-seller and one-time buyers in a low-trust environment. From the seller's point of view, the risk of a reversal might not be acceptable (basically, he cannot assess the probability of it, while the cost is substantial), because the value is too high, so he needs irreversibility. From the buyer's point of view, the risk of losing the money is not catastrophic, but highly undesirable; he wants to be able to name-and-shame the fraud. This would provide the seller
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
On 10/20/05, R.A. Hettinga [EMAIL PROTECTED] wrote: At 12:32 AM +0200 10/21/05, Daniel A. Nagy wrote: Could you give us a reference to this one, please? Google is your friend, dude. Before making unitary global claims like you just did, you might consider consulting the literature. It's out there. You're such an asshole. Daniel's actual statement was simply: I know of no protocol for transfering blinded tokens with a receipt, but I do not rule out the possibility of its existence. This is what you characterized as a unitary global claim. Aside from the fact that unitary is meaningless in this context, his claim was far from global. Instead it was a very modest statement about what aspects of the technology he was familiar with, and explicitly admitted the possibility that he might be mistaken. I don't think you could ask for anything more in a world where no one has perfect knowledge about any topic. While Daniel Nagy has been a model of politeness and modesty in his claims here, you have reverted to your usual role as an arrogant bully. If Daniel's project should be successful then you will undoubtedly switch over to your other mode of communication, obsequious ass-kissing. I have experienced both from you, in my many names and roles, and I have no taste for either one. I would encourage Daniel not to waste any more time interacting with Hettinga. CP
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
On 10/19/05, Daniel A. Nagy [EMAIL PROTECTED] wrote: http://www.epointsystem.org/~nagydani/ICETE2005.pdf Note that nowhere in my paper did I imply that the issuer is a bank (the only mentioning of a bank in the paper is in an analogy). This is because I am strongly convinced that banks cannot, will not and should not be the principal issuers of digital cash-like payment vehicles. If you need explaination, I'm willing to provide it. I do not expect payment tokens to originate from withdrawals and end their life cycles being deposited to users' bank accounts. Suppose we consider your concept of a transaction chain, which is formed when a token is created based on some payment from outside the system, is maintained through exchanges of one token for another (we will ignore split and combine operations for now), and terminates when the token is redeemed for some outside-the-system value. Isn't it likely in practice that such transaction chains will be paid for and redeemed via existing financial systems, which are fully identified? A user will buy a token using an online check or credit card or some other non-anonymous mechanism. He passes it to someone else as a cash-like payment. Optionally it passes through more hands. Ultimately it is redeemed by someone who exchanges it for a check or deposit into a bank or credit card account. If you don't see this as the typical usage model, I'd like to hear your ideas. If this is the model, my concern is that in practice it will often be the case that there will be few intermediate exchanges. Particularly in the early stages of the system, there won't be that much to buy. Someone may accept epoints for payment but the first thing he will do is convert them to real money. A typical transaction will start with someone buying epoints from the issuer using some identified payment system, spending them online, and then the recipient redeems them using an identified payment system. The issuer sees exactly who spent, how much they spent and where they spent it. The result is that in practice the system has no anonymity whatsoever. It is just another way of transferring value online. Using currency is, essentially, a credit operation, splitting barter into the separate acts of selling and buying, thus making the promise to reciprocate (that is the eligibility to buy something of equal value from the buyer) a tradeable asset itself. It is the trading of this asset that needs to be anonymous, and the proposed system does a good enough job of protecting the anonymity of those in the middle of the transaction chains. The hard part is getting into the middle of those transaction chains. Until we reach the point where people receive their salaries in epoints, they will have little choice but to buy epoints for real money. That puts them at the beginning of a transaction chain and not in the middle. Sellers will tend to be at the end. The only people who could be in the middle would be those who sell substantially online for epoints and who also find things online that they can buy for epoints. But that will be a small fraction of users. For the rest of them, anonymity is not a sellling point of this system. If you take away the anonymity, is this technology still valuable? Does it have advantages over other online payment systems, like egold, credit cards or paypal? CP
Re: Judy Miller needing killing
On 10/18/05, Major Variola (ret.) [EMAIL PROTECTED] wrote: So this dupe/spy/wannabe journalist thinks that journalists should be *special*.. how nice. Where in the 1st amendment is the class journalists mentioned? She needs a WMD enema. We put up with this needs killing crap from Tim May because he was imaginative and interesting, at least when he could shake free from his racism and nihilism. You on the other hand offer nothing but bilious ignorance. If you don't have anything to say, how about if you just don't say it? The notion that someone who is willing to spend months in jail just to keep a promise of silence needs killing is beyond bizarre and is downright evil. This list supports the rights of individuals to tell the government to go to hell, and that is exactly what Judy Miller did. She should be a hero around here. It's disgusting to see these kinds of comments from a no-nothing like Major Variola. CP
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
Let's take a look at Daniel Nagy's list of desirable features for an ecash system and see how simple, on-line Chaum ecash fares. http://www.epointsystem.org/~nagydani/ICETE2005.pdf One of the reasons, in the author s opinion, is that payment systems based on similar schemes lack some key characteristics of paper-based cash, rendering them economically infeasible. Let us quickly enumerate the most important properties of cash: 1. Money doesn't smell. Cash payments are -- potentially -- _anonymous_ and untraceable by third parties (including the issuer). This is of course the main selling point of Chaum's system, where it excels. I will point out that defining cash as merely potentially anonymous leaves a loophole whereby fully non-anonymous systems get to call themselves cash. This underplays the strength of Chaum's system. It is not just potentially anonymous, it has a strong degree of anonymity. 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. 3. Cash payments are _peer-to-peer_. There is no distinction between merchants and customers; anyone can pay anyone. In particular, anybody can receive cash payments without contracts with third parties. Again this is precisely how Chaum ecash works. Everyone can receive ecash and everyone can spend it. There is no distinction between buyers and vendors. Of course, transactions do need the aid of the issuer, but that is true of all online payment systems including Daniel's. 4. Cash allows for acts of faith or _naive transactions_. Those who are not familiar with all the antiforgery measures of a particular banknote or do not have the necessary equipment to verify them, can still transact with cash relying on the fact that what they do not verify is nonetheless verifiable in principle. I have to admit, I don't understand this point, so I can't say to what extent Chaum ecash meets it. In most cases users will simply use their software to perform transactions and no familiarity is necessary with any antiforgery or other technical measures in the payment system. In this sense all users are naive and no one is expected to be a technical expert. Chaum ecash works just fine in this model. 5. The amount of cash issued by the issuing authority is public information that can be verified through an auditing process. This is the one aspect where Chaum ecash fails. It is a significant strength of Daniel Nagy's system that it allows public audits of the amount of cash outstanding. However note that if the ecash issuer stands ready to buy and sell ecash for real money then he has an incentive not to excessively inflate his currency as it would create liabilities which exceed his assets. Similarly, in a state of competition between multiple such ecash issuers, any currency which over-inflates will be at a disadvantage relative to others, as discussed in Dan Selgin's works on free banking. Daniel Nagy also raised a related point about insider malfeasance, which is also a potential problem with Chaum ecash, but there do exist technologies such as hardware security modules which can protect keys in a highly secure manner and make sure they are used only via authorized protocols. Again, the operators of the ecash system have strong incentives to protect their keys against insider attacks. The payment system proposed in (D. Chaum, 1988) focuses on the first characteristic while partially or totally lacking all the others. In summary, I don't think this is true at all. At least the first three characteristics are met perfectly by Chaumian ecash, and possibly the fourth is met in practice as naive users can access the 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. There do exist technical proposals for ecash systems such as that from Sander and Ta-Shma which allow monitoring the amount of cash which has been issued and redeemed while retaining anonymity and unlinkability, but those are of questionable efficiency with current technology. Perhaps improved versions of such protocols could provide a payment system which would satisfy all of Daniel Nagy's desiderata while retaining the important feature of strong anonymity. CP
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
Just presented at ICETE2005 by Daniel Nagy: http://www.epointsystem.org/~nagydani/ICETE2005.pdf Abstract. In present paper a novel approach to on-line payment is presented that tackles some issues of digital cash that have, in the author s opinion, contributed to the fact that despite the availability of the technology for more than a decade, it has not achieved even a fraction of the anticipated popularity. The basic assumptions and requirements for such a system are revisited, clear (economic) objectives are formulated and cryptographic techniques to achieve them are proposed. This is a thorough and careful paper but the system has no blinding and so payments are traceable and linkable. The standard technique of inserting dummy transfers is proposed, but it is not clear that this adds real privacy. Worse, it appears that the database showing which coins were exchanged for which is supposed to be public, making this linkage information available to everyone, not just banking insiders. Some aspects are similar to Dan Simon's proposed ecash system from Crypto 96, in particular using knowledge of a secret such as a hash pre-image to represent possession of the cash. Simon's system is covered by patent number 5768385 and the ePoint system may need to step carefully around that patent. See http://www.mail-archive.com/cpunks@einstein.ssz.com/msg04483.html for further critique of Simon's approach. CP
