[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ecash protocol: Part 1

In article <[email protected]>,
Hal  <[email protected]> wrote:
>Ian Goldberg <[email protected]> writes:
>>Last week, I was taking a look at the ecash protocol (no, I don't have a copy;
>>I have a binary, which I can't even run...).  
>>I've managed to decipher a useful bit of the first message sent from
>>the shop to the payer.  It's the Payment Request, and contains the following
>>o Header identifying packet as Payment Request
>>o The integer 4
>>o The payment amount, in cents
>>o The time (seconds since 1970)
>>o The integer 79
>>o The name of the shop (payee)
>>o A description of the item being paid for
>>o An empty string
>>o The integer 0
>>o End of Record marker
>That's very interesting work!  What are the string formats, are they null
>terminated or Pascal-style with a preceding count byte?  How did you
>identify "an empty string", wouldn't that just be a byte of 0?  How did
>you know it was an empty string rather than just a 0.

See below.

>Did you get this by inducing a shop to send a payment request message to
>some program you wrote which was listening on the ecash port?

Yup.  I just had a program sitting on the ecash port that hexdumped
anything fed to it.  That, and a copy of the binary to read...

>I wonder if it would be legal to write shop software which sent such a
>payment request, took the resulting coins, and deposited them in the bank
>(if we could figure out all the protocols necessary).  This particular
>sequence of operations would not appear to infringe anybody's patents -
>there are no blinding operations involved.  It's not clear how useful
>such a program would be but at least it would be one step away from the
>DigiCash monopoly.

 From what I gathered from Doug's posts a little while back, the _client_
stuff is perfectly fine; only the _bank_ stuff is Chaum-patented.

Here are the messy byte-details:

The data encoding:
Header:  2 bytes

0xa0 0x80+type

where type is:

0x12: Payment Request
0x0a: Payment
0x29: Length of Message
0x13: Dummy Message
(there are others)
EOR: 1 byte


End of Record indicator
n-byte Integer:

0x90 0x80+n followed by n bytes of data, MSB first

n should probably be 1 <= n <= 4.
Date: 4 bytes

0x91 0x84 followed by 4 bytes of time since 1970

0x92 0x80+(length) followed by (length) bytes

0x94 0x80+(length) followed by (length) bytes
There are other types, like 0x93 (Multi-precision integer) that I
haven't decoded yet.


The first message from the shop:

a0b9 9083 0000 37a1                         # ......7.

a092 9081 0490 810a 9184 30ad 1930 9081     # ..........0..0..
4f92 8c65 7368 6f70 4063 322e 6f72 6792     # [email protected]
9063 6769 2d62 696e 2f64 6f72 656d 6169     # .cgi-bin/doremai
6c92 8090 8100 a1                           # l......

What it means:

a0b9: Header (Message length)
9083 000037: integer = 0x37 (length of following message)
a1: EOR

a092: Header (Payment Request)
9081 04: integer = 4
9081 0a: integer = 10 (cost in cents)
9184 30ad1930: time
9081 4f: integer = 79
928c "[email protected]" : string (payee)
9290 "cgi-bin/doremail" : string (description)
9280 : empty string
9081 00: integer = 0
a1: EOR

   - Ian