ecash protocol: Part 1
Well, I dropped off the net for a few days due to a midterm, but I'm back now... 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 I don't know what the 4, 79, empty string, and 0 are for. I assume one of them (probably the 4) is some indication of currency (US cents). I can provide a byte-level description of the record, if people want. I guess the important bit is that the payee, the item being bought, and the cost are sent _in the clear_. Some of the people I've talked to think this is a huge privacy breach, and some don't. You all can debate this now. Lucky can, if he wishes, add insight, and/or tell us what DC may do about this. I'll try to figure out the rest of the fields, and some of the other messages (like the payment itself). - Ian "Why exactly isn't DigiCash releasing the protocol? What about the source?"
Ian Goldberg <iang@cory.EECS.Berkeley.EDU> 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. 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? I think a good way to get the rest of the information would be with a proxy which logged message traffic. I know ecash has some proxy support but I'm not sure how it works. There are SOCKS proxies and http proxies, and I don't know which it uses. I used a logging httpd proxy to derive the data for the SSL challenges I did this past summer. It might be interesting to post the binary data from some ecash transactions.
I guess the important bit is that the payee, the item being bought, and the cost are sent _in the clear_. Some of the people I've talked to think this is a huge privacy breach, and some don't. You all can debate this now. Lucky can, if he wishes, add insight, and/or tell us what DC may do about this.
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. Hal
-----BEGIN PGP SIGNED MESSAGE----- Hello Ian Goldberg <iang@cory.EECS.Berkeley.EDU> and cypherpunks@toad.com ...
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...). ...
Sounds like good work! ...
I guess the important bit is that the payee, the item being bought, and the cost are sent _in the clear_. Some of the people I've talked to think this is a huge privacy breach, and some don't. You all can ...
Yeah, it probably is. Then again you can probably use a dummy description, no? However, that doesn't get around the fact that anyone intercepting the packet who knows where it came from will immediately see straight through payer anonymity. ...
- Ian "Why exactly isn't DigiCash releasing the protocol? What about the source?" ...
A Source Close To Digicash That Did Not Wish To Be Quoted once described them as 'crown jewels' (competitive advantage). ASCTDTDNWTBQ then appealed to Digicash's track record. I certainly hope that this genuinely is not Digicash's official opinion. Thank you for once again showing the futility of security by obscurity. Jiri - -- If you want an answer, please mail to <jirib@cs.monash.edu.au>. On sweeney, I may delete without reading! PGP 463A14D5 (but it's at home so it'll take a day or two) PGP EF0607F9 (but it's at uni so don't rely on it too much) -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMLbIjixV6mvvBgf5AQFKiwP/fJKIZnRM4HQzkdzYNTTDPP/CZNGlLWQI UnA4la2134SoBde/hPsSiniuWBlESU8rpbA3IX+mygh50x/4CSb86VClvgIF8xKp XFRwXljxer2dqKV3troMYFQfYWrUoj6NXTJIRQWwBJ6ilHcXE1OWtHWGPgAB9/Gv 79z3R4njwmw= =OPp0 -----END PGP SIGNATURE-----
On Sat, 25 Nov 1995, Jiri Baum wrote:
- Ian "Why exactly isn't DigiCash releasing the protocol? What about the source?" ...
A Source Close To Digicash That Did Not Wish To Be Quoted once described them as 'crown jewels' (competitive advantage). Can you say RC4?
ASCTDTDNWTBQ then appealed to Digicash's track record.
I certainly hope that this genuinely is not Digicash's official opinion.
Heh. Can you say RSADSI? (or Ron Rivest? Or NSA on Mr. Blaze's bogus LEAFs? Need I say Elementrix non-algorithmic POTP?) They were lucky Rivest's a decent cryptographer. (which reminds me, what's the current list of "secure" block ciphers, besides for des and idea? what's been analyzed or weakened lately? I'm too broke to get Schneier's 2nd ed. to check.)
Thank you for once again showing the futility of security by obscurity.
As Ian himself is demonstrating.
In article <199511212146.NAA11456@cory.EECS.Berkeley.EDU>, Ian Goldberg <iang@cory.EECS.Berkeley.EDU> wrote:
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
I don't know what the 4, 79, empty string, and 0 are for. I assume one of them (probably the 4) is some indication of currency (US cents).
I now know what the empty string and the 0 are for. In the event that a Payment Request is sent out-of-band (in an application/ecash message, for example), the string and integer are the hostname and port (commonly 1100) to which the payer should connect in order to send a payment. - Ian "Wait for it..."
In article <199511230103.RAA15911@jobe.shell.portal.com>, Hal <hfinney@shell.portal.com> wrote:
Ian Goldberg <iang@cory.EECS.Berkeley.EDU> 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 # O..eshop@c2.org. 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 "eshop@c2.org" : string (payee) 9290 "cgi-bin/doremail" : string (description) 9280 : empty string 9081 00: integer = 0 a1: EOR - Ian
participants (5)
-
Hal -
iagoldbe＠calum.csclub.uwaterloo.ca -
Ian Goldberg -
Jiri Baum -
s1113645＠tesla.cc.uottawa.ca