From: Hal <hfinney@shell.portal.com>
Date: Sun, 3 Dec 1995 11:53:38 +0800
To: iang@cory.EECS.Berkeley.EDU
Subject: Re:  Questions/Comments on ecash protocol
Message-ID: <199512030334.TAA18144@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


From: Ian Goldberg <iang@cory.EECS.Berkeley.EDU>
> I read these specs for a little while last night.  Here are some of my
> questions/comments.  To prevent this message from becoming huge, I won't
> quote much from the protocol document itself; the URL is above if you want it.
> I'll ignore the spelling/grammar; they can be fixed later.

I was also reading it, and I share some of Ian's questions, but for some
things I have a few different guesses.

> What is the function f, used in the payment_hdr to hash the payer_code
> and desc fields, as well as in WITHDRAW3 to calculate N = f(n) * r**h?
> There is reason to believe it is SHA, but I thought I saw some stuff in the
> client that indicated that the output of f is 132 _bytes_ long (but I'm
> not exceptionally sure of this, not having source and all).

One rather cryptic sentence, which Ian alludes to later, relates to
cancelling payments:  "The 'payer_hash' is the one-way image of a by
the payer generated random number...".  In the diagram it shows it as
f(payer_code), where payer_code is shown as "random code generated by
player".  (And, as Ian points out later, the document inconsistently
says that "the player generated random number" should be kept secret
while requiring that it be sent to the shop - at least, this is
inconsistent if it refers to payer_code.)  Assuming the use of the word
"a" is not a typo but refers to some number, this suggests that f() is
at least potentially a two-input function, some value a and a player
generated random number.

> Please clarify what parts of the payment_hdr are shipped around.  The document
> says that the shop checks if the descr_hash matches the description.
> Since the description is in the second part of the payment_hdr, does that
> mean that both parts are sent to the shop?  Noticing that the payer_code
> (which the payer is supposed to keep secret) is in the second part, this
> doesn't seem to be right.  Also, the document states that the payment hash
> is not sent from the payer to the shop or from the shop to the mint.  However,
> the payment hash is just the SHA of the first part of the payment_hdr,
> which _is_ sent around, so although the payment hash isn't transmitted
> per se, it can certainly be calculated.

It seems that the whole payment_hdr is sent to the shop, and only the
portion before the line is sent to the bank.  This is enough, as you say,
to calculate the payment hash, so the bank can decrypt the coins.  This
prevents the shop from changing any of the information in that first part
of the payment header before sending it to the bank.

My question in this part relates to coins made out to "@" which we have
been told can be deposited by anyone.  How does the bank know to which
account to deposit such a coin, given a deposit message?  The shop's ID
does not seem to be present in such a message, assuming that the
shop_accID field of the payment_hdr just has "@" in that case.  Is it the
userid field in the userhdr message which tells the bank this info?

BTW since apparently both deposit and payment messages are not encrypted,
coins made out to "@" are in danger of being stolen both while en route
from customer to shop and from shop to bank.  This is significant from
the point of view of payee anonymous systems, which will need to use such
coins.  More encryption will be necessary when such coins are passed
around.

> A (very slight) privacy concern: the payer's bank is sent in the clear,
> which gives a very small amount of information about the identity of the
> payer.  More on who knows what later.

Well, I would think identification of the payer's bank will be
necessary for any coin based system so you know where to cash in the
coins, so I don't think this is going to go away.  Of course as of now
everyone has the same bank so it is not an issue.

> Is it in fact the case that all coins on one payment use the same payment hash
> when encrypting their signatures (the field sig in onl_coin)?

The signatures are xor'd with the payment hash, but this is not the main
way they are encrypted - they are then encrypted with the bank's public
key.  The purpose of this xor is not so much to protect the coins as to
bind them unbreakably to the payment header.  Since the coins are always
sent around with that payment header I think they all do use the same
payment hash.

> If (M,e) is the mint's public modulus/exponent, and (N,h) is public mod/exp
> for a particular coin denomination, are the following statements true:
> 
> o If n is the coin number (in onl_coin, assumedly the same n as used in the
>   withdraw request), and hdr is the first part of the payment header,
>   then sig (in onl_coin) equals
> 
>      ([ SHA(hdr) XOR ((f(n)^(1/h)) mod N) ] ^ e) mod M

I was wondering about this too.  There is a reblocking problem in
trying to concatentate "pure RSA" operations.  In particular M must be
at least as big as N.  This is not necessarily a problem, but it is a
slightly unusual constraint on key creation.  However I agree overall
that this formula is a reasonable reading of the doc.

> o A deposit (which contains a userID in the userhdr, a payment_hdr in
>   the dep record, and a pair (n,sig) for each coin) is accepted by the bank iff
> 
>      ([ SHA(payment_hdr) XOR ((sig^(1/e)) mod M) ] ^ h) mod N = f(n)
> 
>   _and_ either payment_hdr.shop_accID corresponds to userID,
> 	  or   a payer_code is supplied such that
> 		 payment_hdr.payer_hash = f(payer_code).

There also needs to be some clause for the "@" payee.  In that case I
think the payment is accepted if the signature checks, with credit to the
userID account.

That business about cancelling via payer_code I agree is not very
sensible.  It doesn't seem necessary - the coin can just be re-spent,
made out to someone else.

> Where is the facility for tracing double spenders?  Perhaps it's just
> part of the "incomplete" part of the document, but I can't even see
> where it would fit in to what we've got; neither the withdrawal nor the
> payment messages seem to encode _any_ information about the payer in
> the coins, and the bank cannot seem to know who withdrew the coin that
> ended up being spent twice (due to the blinding).

There is no such thing!  This is one of the most common misconceptions.
This version of ecash does not trace double spenders.  It prevents double
spending by checking each coin to make sure it has not already been
spent.  Tracing of double spending is only necessary in offline systems
where coins are not checked right away, but that is not present here.

> Is there a way to change the public key associated with an account?
> Is it just a meeter of sending another OPENACC1 message?

My guess is there would need to be some manual intervention to do this.

> Exactly what kind of anonymity/privacy/security does ecash offer?
> Let's examine who knows what.
> [...]
> If Eve or Mitch can determine either r (the blinding factor) used in
> the withdrawal, or the payer_code, used in the payment, they can steal the
> money.  This has ramifications to Doug's "agnostic" banks; more security
> has to be added to the present ecash system if unblinded withdrawals are
> allowed.  This also brings up the "Netscape" question: how are these numbers
> generated?  Does it have to do with that 25 character string you enter
> at the beginning?  I've noticed a bit in the program that seeds a RNG with
> (time(0) ^ ((getpid()<<16)|getuid())).  I think publication of _at least_
> the code pertaining to blinding factor and payer_code generation is
> _absolutely vital_.

Well, as I said, I think this payer_code business is pretty questionable.
I'm sure the next version of the doc will clear that up a great deal.  As
far as determining r, that is not possible from the protocol messages.
Chaum has proven that it is absolutely indeterminate.  So I don't
understand what you mean about "more security has to be added to the
present ecash system if unblinded withdrawals are allowed."  Do you just
mean that the coin messages should not be sent in the clear in that case?
I observed that coin withdrawal messages can be sent in the clear in some
postings I made last year - the use of r effectively encrypts them.  But
of course that can't be done with unblinded messages.

There have been claims that the long string you type in at startup time
deterministically seeds the RNG, so that if you lose your wallet but you
tell DigiCash this string (via some secure channel, presumably) they can
reconstruct the coins you should have.  Presumably they could figure out
what the r values were when you withdrew all your coins, reconstruct the
coin numbers, and see which ones haven't been spent.  This is both good
and bad, in that it provides a well understood amount of entropy (rather
than relying on whatever it can scrounge up), but of course is vulnerable
to lazy typing.  Also, you have to write down the string, and if someone
found this they could perhaps get your coins.

> I think I'll stop here; comments from anyone, and especially answers to my
> questions from DigiCash people, are welcome.  I'm sorry if it's not as
> complete as you (or I) would like; I'm quite tired, as my building had
> two fire alarms in a row at 3am this morning...
> 
>    - Ian "Well, it's a start..."

Very good comments.  I'm sure the next version will be much better if
they are careful to clear up the kinds of issues you have raised.

Hal