1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <eric@voskuil.org>) id 1YQ1zs-000285-1O
for bitcoin-development@lists.sourceforge.net;
Mon, 23 Feb 2015 23:01:04 +0000
X-ACL-Warn:
Received: from mail-pd0-f178.google.com ([209.85.192.178])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YQ1zr-000580-17
for bitcoin-development@lists.sourceforge.net;
Mon, 23 Feb 2015 23:01:04 +0000
Received: by pdjg10 with SMTP id g10so28869950pdj.1
for <bitcoin-development@lists.sourceforge.net>;
Mon, 23 Feb 2015 15:00:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:cc:subject:references:in-reply-to:content-type;
bh=e6SCHUYp9FX5tprL3iXnnn0mD2bPSAlXI48ohpNaTPY=;
b=GUZOXiO2Fycd2Rgij7JRmOYCulpxAmSIB68E4DPEvR3M43Y2gk4eKt8vhhqmlD57ZH
wLKCjoAivpPjl/m9/nrx+amzd5fkpLdcVln0dLIxqap2gE0tUhl37D1T42/Yqt+T1AYx
ArDPjQMNDRIetnL+Ff3eQ9j5TydjUF4klmxYSqCXEsMHQjof5Ib7TwXWRzAKezGXnMlm
wxw5PttJMlmw6PyGcab3L97JrVAuHbXT65CRB5CqcD2jDRYZ6FQiUDkSfsT7VFE8q+xC
mGGBMqKMpWXiA3K9I+ybrXjgxWeZ3o+nKmh93Ge9LuBRp/T//bbPpsj/8OjljPsDaY77
bK9Q==
X-Gm-Message-State: ALoCoQkmCtkFtadWAaqlNEsl2YJOiU9Z1b/a3oMo2H0FFBZyKqs5/CjL0juC7ZmCBCIbHCVPuD2M
X-Received: by 10.70.39.33 with SMTP id m1mr23322454pdk.2.1424732456208;
Mon, 23 Feb 2015 15:00:56 -0800 (PST)
Received: from [10.0.1.3] (c-50-135-46-157.hsd1.wa.comcast.net.
[50.135.46.157])
by mx.google.com with ESMTPSA id n5sm8207567pdh.27.2015.02.23.15.00.54
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 23 Feb 2015 15:00:55 -0800 (PST)
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"
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1YQ1zr-000580-17
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
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2015 23:01:04 -0000
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--
|
