Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

2005-10-19 Thread Daniel A. Nagy
On Tue, Oct 18, 2005 at 11:27:53PM -0700, cyphrpunk wrote:
   Just presented at ICETE2005 by Daniel Nagy:
 
   http://www.epointsystem.org/~nagydani/ICETE2005.pdf
 
 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.

At the time of writing, I was already familiar with Simon's proposal and its
above mentioned critique (I learnt about them from Stefan Brands' blog). At
that time, the design and the implementation were already complete and the
process of writing up the paper was also well advanced. Wishing to postpone
the discussion of patents for as long as possible, I decided against citing
Dan Simon's work in references, which may be regarded as an act of academic
dishonesty on my part. Mea culpa. I am reasonably confident that I can
legally defend the point that there are sufficient differences between my
proposal and Simon's, but I might not be ready to fight off a legal assault
from Microsoft (lack of time and money) right now. Leaving the patent issue
at that, let us proceed to the substance.

I will probably need to write another paper, clarifiing some of these
issues. Let me, however, re-emphasize some of the points already present in
the paper and perhaps cast them in a slightly different light.

In my paper, I am explicitly and implicitly challenging Chaum's assumptions
about the very problem of digital cash-like payment. One can, of course,
criticize my proposal under chaumian assumptions, but that would miss the
point entirely. I think, a decade of consistent failure at introducing
chaumian digital cash to the market is good enough a reason to re-think the
problem from the very basics.

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.

Insider fraud is a very serious risk in financial matters. A system that
provides no safeguards against a fraudulent issuer will sooner or later be
exploited that way. Financial systems (not just electronic ones) often fall
to insider attacks. They must be addressed in a successful system. All
chaumian systems are hopelessly vulnerable to insider fraud.

And now some points missing from the paper:

Having a long-term global secret, whose disclosure leads to immediate,
catastrophic failure of the whole system is to be avoided in security
engineering (using Schneier's terminology, it makes a hard system brittle).
The private key of a blinding-based system is exactly such a component. Note
that in the proposed system, the digital signature of the issuer is just a
fancy integrity protection mechanism for public records, which can be
supplemented and even temporarily substituted (while a new key is phased in
in the case of compromise) by other mechanisms of integrity protection. It
is the public audit trail that provides most of the security.

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.

Hope, this helps.

-- 
Daniel



Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

2005-10-20 Thread Daniel A. Nagy
I will provide a detailed answer a bit later, but the short answer is that
anonymity and untraceability are not major selling points, as experience
shows. After all, ATMs could easily record and match to the user the serial
numbers of each banknote they hand out, yet, there seems to be no preference
to coins vs. banknotes.

The major selling point, as noted in the paper and in the presentation is
that the security (and hence the transaction cost manifesting itself in the
effort required for each transaction) scales with transaction value. For
paying pennies, you just type, say, 12-character codes. Yet, if the
transaction value warrants it, you can have a full-fledged, digitally signed
audit trail within the same system. And it's completely up to the users to
decide what security measures to take.

Another important issue is that you never risk more than the transaction
value. There is no identity to be stolen.

So, in short, the selling point is flexible and potentially very high
security against all sorts of threats. Someone finding out who you might be
is not, by far, the most serious threat in a payment system.

-- 
Daniel



Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

2005-10-20 Thread Daniel A. Nagy
Thank you for the detailed critique!

I think, we're not talking about the same Chaumian cash. The referred 1988
paper proposes an off-line system, where double spending compromises
anonymity and results in transaction reversal. I agree with you that it was
a mistake on my part to deny its peer-to-peer nature; should be more careful
in the future.

I strongly disagree that potentially anonymous systems do not deserve to be
called cash. For the past approx. 100 years, banknotes have been used as
cash and there seems to be no preference on the market for coins, even
though banknotes have unique serial numbers and are, therefore, traceable.
I maintain, that anonymity and untraceability are primarily not privacy
concerns but -- to some extent -- necessary conditions for irreversibility,
which is the ture reason why cash is such a mainstay in commerce and why I
would expect its electronic equivalent would be a desirable financial instrument
in the world of electronic commerce. In a low-trust environment,
irreversible payments are preferable to reversible ones.

Simple on-line Chaumian blinded tokens, where the value is determined by the
public key and the signed content is unimportant, as long as it is unique,
are more like coins. And the most serious problem with them is that of
transparent governance. Unfortunately, those hyperinflating their currency
are not caught early enough. One way to handle this problem is by expiring
tokens. For example, for each value, keys can be introduced in a brick-wall
pattern: keys are replaced in regular intervals with two keys being valid at
all times, with one expiring in the middle of the lifetime of the other.
Tokens signed by the old key are always excahnged for those signed by the
new one. This would allow a regular re-count of all tokens in circulation
(by the time a key expires, at most as many tokens would have been exchanged
for the next key as have been issued), but it raises other concerns.

With simple blinded tokens, naive transactions are possible only with the
already unblinded ones. One can accept them on faith, and pass on without
exchanging. This does not require additional equipment/software.

I know of no protocol for transfering blinded tokens with a receipt, but I
do not rule out the possibility of its existence.

Without it, however, the blinded tokens are useful for a very narrow range
of transaction values. Namely, those small enough not to be bothered about
receipts, but large enough so that the effort of making a payment does not
exceed the transaction value. This confines their usability to part of the
micropayment market.

To reiterate, the main advantage of the proposed system is that it allows
for a very large range of transaction values by providing adequate security
for high-value ones, while requiring extremely little effort for low-value
ones. And all that at the sole discretion of the users.

Regards,

-- 
Daninel



Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

2005-10-21 Thread Daniel A. Nagy
On Thu, Oct 20, 2005 at 07:34:34PM -0400, R.A. Hettinga 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.

With all due respect, this was unnecessarily rude, unfair and unwarranted.
Silvio Micali is a very prolific author and he published more than one paper
on more than one exchange protocol. I am actually familiar with some of his
work on the subject. I was, however, specifically interested in which
particular one did you have in mind. I can think of several exchange
protocols that would do the job, though I don't particularly like them,
because the infrastructure for carrying them out is not in place and they
require more communication than is strictly necessary for obtaining a receipt.

In general, I think that one should be very careful with piling up
cryptographic operations and additional back-and-forth communication steps
in a payment protocol, because it may easily render it unpractical. There
are reasons why there are no cash-like digital payment systems, and it's not
for the lack of trying (you know that better than anybody else in the world,
I guess) or the lack of demand. Making it sufficiently simple is one of the
most difficult challenges.

-- 
Daniel



Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

2005-10-21 Thread Daniel A. Nagy
On Thu, Oct 20, 2005 at 05:19:49PM -0400, R.A. Hettinga wrote:

 BTW, you can exchange cash for goods, or other chaumian bearer certificates
 -- or receipts, for that matter, with a simple exchange protocol. Micali
 did one for email ten years ago, for instance.

Could you give us a reference to this one, please?

Thank you in advancne!

-- 
Daniel



Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

2005-10-21 Thread Daniel A. Nagy
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.

 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 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).

I claim that a system that provides both features will be prefered by users
to one that provides only one or neither.

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 with enough incentives to deliver
and enough security to go ahead with the deal.

The legal system in this case is just provable reputation-tracking, which
in case of non-performance deprives the seller of future custom.

-- 
Daniel



Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

2005-10-25 Thread Daniel A. Nagy
One intresting security measure protecting valuable digital assets (WM
protects private keys this way) is inflating them before encryption.

While it does not protect agains trojan applications, it does a surprisingly
good job at reducing attacks following the key logging + file theft pattern.

This security measure depends on two facts: storage being much cheaper than
bandwidth and transmission of long files being detectable, allowing for
detecting  and thwarting an attack in progress.

-- 
Daniel



Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

2005-10-25 Thread Daniel A. Nagy
On Mon, Oct 24, 2005 at 02:58:32PM -0700, cyphrpunk wrote:

 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, there have been several attacks of this kind against Russia's WebMoney
system. One of the founders and first arbiters, Nikita Sechenko, wrote up
the following text on his advocacy webpage owebmoney.ru (my translation):
https://www.financialcryptography.com/mt/archives/000492.html

It also contains somre relevant bits about governing an payment system based
on pseudonymous accounts. I think, theirs is the most sophisticated
account-based payment system in active use, complete with arbitration,
messaging, billing, key certification, credit operations and credit history,
and a lot more.

-- 
Daniel



Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

2005-10-31 Thread Daniel A. Nagy
On Fri, Oct 28, 2005 at 02:18:43PM -0700, cyphrpunk wrote:

 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.

I agree, this discussion is missing, indeed. I will definitely include it,
should I write another paper on the subject.

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.

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.

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.

-- 
Daniel