Message-ID: <54EBB10D.8020502@voskuil.org>
Date: Mon, 23 Feb 2015 15:00:29 -0800
From: Eric Voskuil <eric@voskuil.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Mike Hearn <mike@plan99.net>
References: <20150222190839.GA18527@odo.localdomain>	<54EA5A1C.2020701@AndySchroder.com>	<54EA60D9.8000001@voskuil.org>	<54EA66F5.2000302@AndySchroder.com>	<mcdu6b$j11$1@ger.gmane.org>	<54EAD884.8000205@AndySchroder.com>	<mcet2t$qav$1@ger.gmane.org>	<54EAFC1C.9080502@voskuil.org>
	<CANEZrP0XYfnarvN5H_NeOGyO8RLBSGyGxv7M63MSrAd_HXj1OQ@mail.gmail.com>
In-Reply-To: <CANEZrP0XYfnarvN5H_NeOGyO8RLBSGyGxv7M63MSrAd_HXj1OQ@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="Vm5NgPEhTBoL6QGFP78M99PQGE1T3rQn3"
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70,
 NFC and offline payments - implementer feedback
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Vm5NgPEhTBoL6QGFP78M99PQGE1T3rQn3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Mike,

Before addressing other issues I could use some clarification on your
intent.

In one statement you refer to derivation of a session key from a bitcoin
address (passed via NFC):

> doing ECDH over secp256k1 to derive a session key means we can reuse
> the address that was put in the URI already for pre-BIP70 wallets

In another statement you refer to derivation of a session key from a
public key (passed via  BT):

> The public key can then be provided in full in the clear over the
> Bluetooth connection and the session key derived.

I don't see how you propose to treat the bitcoin address as a secp256k1
public key, or do you mean something else?

e

On 02/23/2015 02:58 AM, Mike Hearn wrote:
>     DHKE will not improve the situation. Either we use a simple method =
to
>     transfer a session key or a complex method.
>=20
> You're right that just sending the session key is simpler. I originally=

> suggested doing ECDHE to set up an encrypted channel for the following
> reasons:
>=20
>  1. URIs are put in QR codes more often than NFC tags. QR codes have
>     limited space. The more stuff you pack into them, the slower and
>     flakier the scanning process becomes.
>=20
>     For normal wallets, doing ECDH over secp256k1 to derive a session
>     key means we can reuse the address that was put in the URI already
>     for pre-BIP70 wallets, thus we don't have to expand the URI at all
>     except perhaps to flag that crypted Bluetooth connections are
>     supported. Win!
>=20
>  2. If the wallet is a watching wallet, this won't work and in that cas=
e
>     you would need to put a separate key into the URI. However, this ke=
y
>     is ephemeral and does not need to be very strong. So we can generat=
e
>     a regular secp256k1 key and then put say 5-8 prefix bytes into the
>     URI as a new parameter. The public key can then be provided in full=

>     in the clear over the Bluetooth connection and the session key
>     derived. If we put the session key into the URI in full, then we
>     could not use this trick. Win!
>=20
>  3. It's quite common in low tech scenarios like little coffee shops to=

>     just print a QR code and put it in the menu, or sticky tape it to
>     the back wall of the shop.
>=20
>     In these cases, it's possible that the device is actually hanging
>     around in the shop somewhere but having the QR code somewhere large=
r
>     and more accessible than the shop devices screen is highly
>     convenient. However it means the data is entirely static.
>=20
>     Putting/reusing an identity key from the URI means the session keys=

>     are always unique and known only to both devices, even though the
>     bootstrap data is public.
>=20
>  4. Doing ECDHE to derive the keys means we can derive a MAC key as wel=
l
>     as an AES key. Otherwise you have the issue of exchanging both,
>     which again uses up valuable bootstrap space.
>=20
> So for a small increase in session setup complexity we potentially avoi=
d
> troubling problems down the line where people the same functionality
> from NFC and QR code based bootstrap, but we can't provide it.
>=20
> These discussions keep coming up. I think the next step is for someone
> to upgrade Andreas' wallet to support encrypted connections and the
> TBIPs, to see what happens.
>=20
> Re: the h=3D parameter. I only objected to requiring this when the paym=
ent
> request is also signed. It adds complexity, uses space, and the
> rationale was "the PKI can't be trusted" even though it's been used to
> protect credit card payments for 20 years without any issues. In the
> case of unsigned payment requests, sure ... but with a proper
> implementation of an encrypted Bluetooth channel it'd be unnecessary as=

> the channel establishment process would guarantee authenticity anyway.
>=20
> But don't let me hold you guys back! I'd rather see something that work=
s
> than an endless debate about the perfect arrangement of hashes and URI
> parameters :)
>=20


--Vm5NgPEhTBoL6QGFP78M99PQGE1T3rQn3
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

iQEcBAEBAgAGBQJU67ElAAoJEDzYwH8LXOFOL3IH/2iNmRryW7Y9KWD3GNssn3pg
b+qHnC9UUtEbu/pBRENVSH0Wfxv4FD/AbvSmK3qhKArokavEnmwP0DFs7Cn4Tbpd
oi2S+TKNJdUCR3JTaA366vNaODzmYhgoaUuqcMMtYnwDNj60i5jI1Iu+QcA7bv6B
1C4Dr5EhU8l+vJ/J+5UzYakyyp1HYEMCIbAdgmD0UGfrTA71/5aCr1abT5EEwxOE
r+RPpslFwC5PNIbRHuHZl7DZPt23fVSRnrlGbIsQomqW7T40vnqyV7kklJxqRj7m
9qFp+DpwybWKT+AIWR/+CI7QHN/qscsG2QyXTe8ElaR4ce9nh1wzZrODzuqjLC0=
=bAgA
-----END PGP SIGNATURE-----

--Vm5NgPEhTBoL6QGFP78M99PQGE1T3rQn3--