Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
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. 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. Apart from the transferability issue, I think there are some systems that do not rely on an issuer at all (in effect any payee is an issuer). Manasse's Millicent comes to mind, but I confess that I don't fully remember the details. Ray
Re: Firm invites experts to punch holes in ballot software
Date: Wed, 07 Apr 2004 15:42:47 -0400 From: Ian Grigg [EMAIL PROTECTED] It seems to me that the requirement for after-the-vote verification (to prove your vote was counted) clashes rather directly with the requirement to protect voters from coercion (I can't prove I voted in a particular way.) or other incentives-based attacks. You can have one, or the other, but not both, right? What you can have is for the voter to be able to verify that his/her vote was properly counted without being able to prove it to anybody else. In that case, an individual claim that a vote was improperly counted wouldn't be convincing, but a wide enough outcry might trigger a recount. I think this would add unnecessary and undesired complexity to a political election voting system, though. Ray
Re: Thanks, Lucky, for helping to kill gnutella
Date: Sat, 10 Aug 2002 16:42:52 +0200 (CEST) From: Eugen Leitl [EMAIL PROTECTED] Calling Lucky a liar is no more illuminating than others calling you an idiot. You're confusing a classification for an argument. The argument is over. You can read it up in the archives. If you think there's still anything left to discuss, I've got these plans of the Death Star I could sell you... I took a look at the archives as you suggested. If it matters to you, I wasn't referring to your classification of Anonymous as an idiot (which I hadn't seen because it wasn't sent to the cryptography list), but rather to an earlier comment (Wow. You must really be an idiot.) from somebody else. Looking back at that message, it appears that it was sent to the cryptography list but not to cypherpunks. Discussion about TCPA/Pd continues, and I hope that disagreements needn't degenerate into name-calling.
Re: Thanks, Lucky, for helping to kill gnutella
Date: Fri, 9 Aug 2002 20:25:40 -0700 From: AARG!Anonymous [EMAIL PROTECTED] Right, as if my normal style has been so effective. Not one person has given me the least support in my efforts to explain the truth about TCPA and Palladium. Hal, I think you were right on when you wrote: But feel free to make whatever assumptions you like about my motives. All I ask is that you respond to my facts. I, for one, support your efforts, even though I don't agree with some of your conclusions. It is clear that you hold a firm opinion that differs from what many others here believe, so in making your points you can expect objections to be raised. You will be more convincing (at least to me) if you continue to respond to these dispassionately on the basis of facts and reasoned opinions (your normal style?). Calling Lucky a liar is no more illuminating than others calling you an idiot.
Re: Challenge to TCPA/Palladium detractors
Date: Fri, 9 Aug 2002 19:30:09 -0700 From: AARG!Anonymous [EMAIL PROTECTED] Re the debate over whether compilers reliably produce identical object (executable) files: The measurement and hashing in TCPA/Palladium will probably not be done on the file itself, but on the executable content that is loaded into memory. For Palladium it is just the part of the program called the trusted agent. So file headers with dates, compiler version numbers, etc., will not be part of the data which is hashed. The only thing that would really break the hash would be changes to the compiler code generator that cause it to create different executable output for the same input. This might happen between versions, but probably most widely used compilers are relatively stable in that respect these days. Specifying the compiler version and build flags should provide good reliability for having the executable content hash the same way for everyone. A trivial observation: this cannot be true across hardware platforms. TCPA claims to be platform and OS agnostic, but Palladium does not.
Re: dangers of TCPA/palladium
Date: Mon, 5 Aug 2002 16:25:26 -0700 From: AARG!Anonymous [EMAIL PROTECTED] The only way that TCPA will become as popular as you fear is if it really solves problems for people. Otherwise nobody will pay the extra $25 to put it in their machine. Although I support the vote-with-your-wallet paradigm, this analysis seems overly simplistic to me. Macrovision doesn't solve problems for most VCR purchasers, but they pay for it anyway. They have no choice. In some cases people are required to buy and use something that they might not otherwise be inclined to pay for, e.g., catalytic converters in automobiles (which also use palladium). It doesn't seem reasonable to similarly require TCPA in computers, but legislators might think (or be lobbied) otherwise. If the fears that some people have expressed prove justified and TCPA becomes primarily a means to enforce draconian copyright restrictions, then people may well choose to pay for it just to regain pre-TCPA functionality. In that case, the problems it solves for them are the same ones it causes!
Re: Challenge to TCPA/Palladium detractors
Date: Wed, 7 Aug 2002 12:50:29 -0700 From: AARG!Anonymous [EMAIL PROTECTED] I'd like the Palladium/TCPA critics to offer an alternative proposal for achieving the following technical goal: Allow computers separated on the internet to cooperate and share data and computations such that no one can get access to the data outside the limitations and rules imposed by the applications. The model and the goal are a bit different, but how about secure multi-party computation, as introduced by Chaum, Crepeau, and Damgard in 1988 and subsequently refined by others?
Re: Challenge to TCPA/Palladium detractors
Date: Thu, 8 Aug 2002 21:55:40 +0200 From: R. Hirschfeld [EMAIL PROTECTED] Date: Wed, 7 Aug 2002 12:50:29 -0700 From: AARG!Anonymous [EMAIL PROTECTED] I'd like the Palladium/TCPA critics to offer an alternative proposal for achieving the following technical goal: Allow computers separated on the internet to cooperate and share data and computations such that no one can get access to the data outside the limitations and rules imposed by the applications. The model and the goal are a bit different, but how about secure multi-party computation, as introduced by Chaum, Crepeau, and Damgard in 1988 and subsequently refined by others? Sorry, I see from an earlier message of yours that you are looking for a simple non-crypto solution, so I guess this doesn't fit the bill. The examples you gave in your earlier message all seem to be equivalent to having the participants send the data to a trusted third party who performs the computation, except that the trusted third party is transplanted to one or more of the participants computers, which are protected against their owners. I guess it boils down to whether or not the level of trust is sufficient. This seems iffy when one of the participants is also the trust provider.
Re: Challenge to David Wagner on TCPA
From: James A. Donald [EMAIL PROTECTED] Date: Tue, 30 Jul 2002 20:51:24 -0700 On 29 Jul 2002 at 15:35, AARG! Anonymous wrote: both Palladium and TCPA deny that they are designed to restrict what applications you run. The TPM FAQ at http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf reads They deny that intent, but physically they have that capability. To make their denial credible, they could give the owner access to the private key of the TPM/SCP. But somehow I don't think that jibes with their agenda. If I buy a lock I expect that by demonstrating ownership I can get a replacement key or have a locksmith legally open it.
