[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
>>information:
>
>>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
0xa1
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
---
String:
0x92 0x80+(length) followed by (length) bytes
---
Data:
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