From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YQOJb-0001j7-DN for bitcoin-development@lists.sourceforge.net; Tue, 24 Feb 2015 22:50:55 +0000 X-ACL-Warn: Received: from uschroder.com ([74.142.93.202]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YQOJZ-0003NC-S0 for bitcoin-development@lists.sourceforge.net; Tue, 24 Feb 2015 22:50:55 +0000 Received: from [192.168.253.4] (cpe-74-137-24-201.swo.res.rr.com [74.137.24.201]) by uschroder.com (Postfix) with ESMTPSA id 2171B22BE0B7B; Tue, 24 Feb 2015 17:50:48 -0500 (EST) Message-ID: <54ED0046.3030906@AndySchroder.com> Date: Tue, 24 Feb 2015 17:50:46 -0500 From: Andy Schroder User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eric Voskuil , bitcoin-development@lists.sourceforge.net References: <20150222190839.GA18527@odo.localdomain> <54EA5A1C.2020701@AndySchroder.com> <54EA60D9.8000001@voskuil.org> <54EA66F5.2000302@AndySchroder.com> <54EAD884.8000205@AndySchroder.com> <54EAF570.2090602@voskuil.org> <54EBE809.70801@voskuil.org> <54EC11DA.2010000@AndySchroder.com> <54EC605B.8080005@voskuil.org> <54ECD5BA.7040109@AndySchroder.com> <54ECF7DB.3060607@voskuil.org> In-Reply-To: <54ECF7DB.3060607@voskuil.org> X-Enigmail-Version: 1.6 OpenPGP: id=2D44186B; url=http://andyschroder.com/static/AndySchroder.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XW5vIEN9SqIfxNHEMM3kv0kkLmOiMEJGj" X-Spam-Score: 0.2 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.2 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YQOJZ-0003NC-S0 Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 22:50:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XW5vIEN9SqIfxNHEMM3kv0kkLmOiMEJGj Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable We can change "resource" to "Session ID" if you want. I think the URL scheme should be: bitcoin:[address]?r=3Dbt:&s=3D But when connecting to the mac, the client indicates the SessionID in=20 the header, and as you say, SessionID is derived in some way from PublicK= ey. This is a slightly different format than both of your suggestions below, = but seems to make more sense based on what you said in your entire=20 message. The other thing is it can be used with more protocols without=20 taking up more space in the URL. However, by loosing the h=3D parameter, I think we are now loosing some=20 benefit it brought to https based connections if the customer doesn't=20 want to use bluetooth. Right? Also, you talk about a new public key (and session ID) for each tap. I=20 guess I'm wondering about this though. If the public key is compromised=20 on the first tap, isn't their payment request already compromised? Since we are securing everything, can we change the message header=20 format from what Schildbach's bitcoin wallet implements to something=20 more consistent? Maybe we can create a new UUID for this secure service=20 so Schildbach's bitcoin wallet can still maintain backwards compatibility= =2E Andy Schroder On 02/24/2015 05:14 PM, Eric Voskuil wrote: >> * Add a "s=3D" parameter that uses a unique public key for each ses= sion. >> This public key identifies the payee to the payer and payer to th= e >> payee. > This would be the simple model, which just tacks on another parameter t= o > the bitcoin URL: > > bitcoin:[address]?bt=3D&s=3D > > But we should also look at the more flexible "r#" approach from your > existing TBIPs, which would yield: > > bitcoin:[address]?r=3Dbt:/ > > and incorporate the "payment_url" list. > >> * Use a base58 encoding to save space and reduce the character set >> slightly. > :) > >> * Get rid of the resource? If a terminal is accepting payment from >> multiple customers simultaneously, it should be smart enough to >> distinguish between customers based on the public key they are >> encrypting the data with. Is this approach feasible? > Yes, it is not necessary on the URL. But an id is useful in helping the= > BT terminal identify the session without having to try all of its > outstanding keys until it finds one that works. > > I proposed that the resource name ("session id" may be a better name) b= e > deterministically derived from the session key. Given the design change= > to pass an EC public key it would need to be derived from that key (not= > from the session key because the receiver would not have a copy before > decrypting the first BT message). So any function on the public key tha= t > reduces it to a smaller length, fixed width should be fine. Hashing it > first may be better as is prevents disclosure of any bits of the public= > key, which should be treated as a secret during the session. > >> * When you said a new public key for each tap, do you see that as >> every single tap, or do you consider multiple taps from the same >> customer the same tap? > Yes, since there would be no other way to distinguish between customers= > in some scenarios and this is the safest approach. We certainly won't > run out of numbers, and unused sessions can be discarded based on any > number of criteria, including discarding all but the most recent. That > may may be sufficient for your vending machines given there's little if= > any call for parallelism. > > e --XW5vIEN9SqIfxNHEMM3kv0kkLmOiMEJGj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJU7QBGAAoJEDT679stRBhrsKsH/RnRYGT12JFqSiIwatN6QLuA 6p5jBvFlY10ttivr64ITF4muirmYFcjW8VQc/IFTX2RgLZImaT0p9cBwtARSNXrT yW0ekjo/3Ap4m6iGeuuK4YOtECEoTMlxG0G5fkXbelLWnstMsZ67AzjRVXc45p7K Z3cq82WljeXfGTCVKa1xsN2xA+UQn5yMpt5KGZrw9DCzRHeYl2uUW9VKylqj6rW6 xc9M1xmKDWtung0Tjx1tNQCn09s5sI7y9TP5B1w/tf9VpQoLhtM1efbknOnSnCpb IW9aqAwyCjE8ou6WxvH9jj0g+TsD9M+P6dTAmDQv4Fw9Iq9QQpNWfkEl7szvqQo= =upi4 -----END PGP SIGNATURE----- --XW5vIEN9SqIfxNHEMM3kv0kkLmOiMEJGj--