From: iang@cs.berkeley.edu (Ian Goldberg)
Date: Sun, 19 May 1996 11:59:17 +0800
To: cypherpunks@toad.com
Subject: My meeting with Chaum (Also: ecash full anonymity and a legal question)
In-Reply-To: <adc276f5060210049520@[205.199.118.202]>
Message-ID: <4nlfee$vcj@abraham.cs.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

In article <adc276f5060210049520@[205.199.118.202]>,
Timothy C. May <tcmay@got.net> wrote:
>I first read of Chaum's work in late '85, in his CACM article, and then
>"rediscovered" it when I was doing some review work for Phil Salin's AMIX
>information market startup in 1987.
>
>Certainly the text of Chaum's articles implied both payer and payee
>anonymity, though certain details may've been unclear to some of us.
>
>When Chaum unveiled his "payer is anonymous, but payee is traceable," some
>of us were surprised.
>
>(On the other hand, I have had a longstanding faith that the system can be
>made to be both payer- and payee-anonymous. Moneychangers, for example.)
>
>>Deal with the devil?
>>
>>Any "complete" digital cash implementation has to provide for payee anonymity.
>>
>
>I agree with Jim Bell on this completely. I don't know if Chaum has been
>seduced by the Dark Side, or is looking to get digicash widely deployed by
>"respectable" institutions, or is telling the truth (that his system
>_never_ provided for real untraceability), but I know that Cypherpunks
>should always strive for full untraceability.
>
>One-sided traceability is not enough.
>

So here's the deal with ecash "as it works today":

If a payment is made with ecash through some anonymous channel (like a remailer
or a post to alt.anonymous.messages), neither the payee or the payor can
directly identify the other (that is to say, neither's identity need be stored
in, or used to construct, the payment).

_However_, in the current implementation, the payor can collude with the bank
to reveal the payee's identity.  More specifically, the payor can produce
the "blinding factor" he used when he withdrew the coins from the bank,
which he later gave to the payee, who deposited them.  The bank can use this
information to figure out what the unblinded coin looked like, and then check
its logs to find out who deposited that coin (remember that with the current
implementation, when a coin is paid to someone, he must immediately deposit it,
or risk losing the money if the payor tries to cancel the payment or spend it
again).

Note that the act of giving up the blinding factor will reveal
_both_ parties in the transaction.  That is, in order to reveal the payee,
the payor must identify himself.  (Not a big deal in the case of LEO...)
This is because what is being identified is a "link" between a blinded coin
that was withdrawn from the payor's account to the unblinded coin that was
deposited to the payee's account.

The way "full anonymity" works is that the coin is blinded by _both_ the payor
and the payee before being withdrawn from the bank.  That way, in order to
reveal the link between the payor and the payee, _all three_ of the bank, the
payor, and the payee must collude.  This is not a big deal (the reasons for
which are left as an exercise).

Relevance:

The ecash "concept" (numbers that _are_ money) produces an inherently
bearer instrument (modulo double spending protection).  The current software
implements payor-side blinding only, in order to appease the Powers That Be.
There's no reason why, given the information currently available, and
even better when the library is released, with a weekend's work
(a week if you're slow), you couldn't produce the handful of functions
you'd need to implement the fully-anonymous protocol, REGARDLESS of whether
you had access to the source to the current client or the library.

The reson I bring this up is that yesterday, I had a 2.5-hour chat with
David Chaum.  These seemed to be the important bits:

o The current plan is to release a lowish-level, binary-only library, as well
  as highish-level source which calls that library, and implements the
  published high-level API (http://www.digicash.com/api/).  Release date: RSN.

o The source to the current client, and the low-level library will _not_ be
  released.  Dr. Chaum's main reason was that releasing the source would make
  it "too easy" to implement full anonymity, which he sees the various
  regulators seeing as a Bad Thing(TM).  I disagreed.  With the recent release
  of the byte-level encoding (http://www.cs.berkeley.edu/~iang/ecash/),
  it would be not too much work for a sufficiently motivated person to
  do, with or without the source.  In fact, it's unclear the source to
  the low-level library is really all that helpful in this respect.

o He doesn't really want there to be an independent implementation of the
  ecash library, with full source available, also for the above reasons.
  The phrase "The worst thing you could do would be to go to Canada, write
  the library, and publish it on the net." came up.  In both this and the
  above case, he didn't believe that availability of source code for
  security analysis (everyone runs code they didn't write) was an important
  issue.  As far as I could tell, he was thinking like a Cryptographer
  (not surprising, as that's what he is (and a damn fine one, at that)):
  he wanted to have a way to verify that the _protocols_ were behaving
  correctly; that is, they were not leaking private information, and that
  money wasn't being lost.  The issue of buffer overruns causing the security
  of my entire machine to be compromised wasn't important.

o Similarly, the source to the mint will not be published.  Notwithstanding
  that the last few bugs I found in ecash were with the mint software, of which
  I've never seen source nor object code, again, thinking like a Cryptographer,
  he insisted that the system was designed so that no matter how one person
  cheats, the others can't be affected.  That may be true in theory, but in
  practice, if there's a fingerd-style hole in the mint software, and someone
  manages to steal the mint's private key, and makes counterfeit ecash,
  does that really not affect me, a customer?  If I'm going to be buying into
  this system, I would like to have some assurance of its security, and
  it is well-known that the best way to do that is to have open source.

So: a question to legal-types, maybe:

I am, in fact, going to Canada, and was considering writing a version of
the library while I was there.  Now, Chaum has a patent on 2 lines of
code (blinding the coin before it goes to the bank, and unblinding the
value returns).  Believe it or not, I would like to stay within the law.
Would my writing a library that worked perfectly well with the current
system, but just didn't do blinding (and thus has no anonymity) be
"contributory infringement" or something like that (noting that it would
likely be trivial for someone to add in the relevant 2 lines)?  Would it
matter (either including the 2 lines or not) if I'd: (a) sell it (b)
give it away on the net (c) give it just to a few people (d) only use it
myself?

Remember also that this would be done in Canada, just to make the question
tougher...

   - Ian "I didn't rant nearly so much as I thought I would..."

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMZ5Ay0ZRiTErSPb1AQFujwQAiQy1nr7pkbk4jQ2wOJREkNFLpEJ33aO3
GoTo0LOa1ej+j/t7AkoGXmc+Udd+HD4VSkEvJE0dwMHkvbb+1DReFhpZ+F7xwf5d
8t9XLKMlL7HbQAxD1Vc2LjgooQxeOoQHyG64ovhPcEwU4v5jF0PWnYex++SKO2Bn
ytYOChOmJ9Q=
=mN0s
-----END PGP SIGNATURE-----