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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <eric@voskuil.org>) id 1YJXMB-0005HE-FE
for bitcoin-development@lists.sourceforge.net;
Fri, 06 Feb 2015 01:05:15 +0000
X-ACL-Warn:
Received: from mail-pa0-f49.google.com ([209.85.220.49])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YJXMA-0004I2-Am
for bitcoin-development@lists.sourceforge.net;
Fri, 06 Feb 2015 01:05:15 +0000
Received: by mail-pa0-f49.google.com with SMTP id fa1so13521141pad.8
for <bitcoin-development@lists.sourceforge.net>;
Thu, 05 Feb 2015 17:05:08 -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=6z33Hxmxj7YmD18C9WzRy4D4bSW1yRY3h0tKPjEptuI=;
b=IAAQhR/x9w86zOkAJG0ALPWHiuiWMKAZZX/ubCoy4PREhbxVdvcuCtcmZQ53nKD4Sl
xAoPy4I4OJGjIfgKgdwbSBHDD5nS3FGgGyYaccxvqJuuB0ypenmraMlTKQEtFFoJ4Fih
rPRxUUFKTLiiU33omV8gm8Y/CPphys2S+uV5lCvtJablTw9mrMeEzpmWHri60fgYkxee
Iy7Um+XCbt1pgnislEu77L9fIt5pMx4jk87/1XcL+NGyb3dvDlWfXWZ9v4KNwOo1Gun3
SJ7d3fEdBgcp52R+P9X9DJW24l6rRlUJ7WmzRlQFlYBg9GgDjGKIYuWLufdzUpTqR7Ih
dgsQ==
X-Gm-Message-State: ALoCoQmQpZq8jZLmvpJ3v58ZXfkRlbMzgGE1M9rTG68uLEhP8IVJIDhlXE90qLKgkhmAqO+SNPAl
X-Received: by 10.68.231.71 with SMTP id te7mr1447071pbc.129.1423184708525;
Thu, 05 Feb 2015 17:05:08 -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
bx10sm6269444pab.25.2015.02.05.17.05.07
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 05 Feb 2015 17:05:07 -0800 (PST)
Message-ID: <54D41353.5050205@voskuil.org>
Date: Thu, 05 Feb 2015 17:05:23 -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: Paul Puey <paul@airbitz.co>, William Swanson <william@airbitz.co>
References: <CABdy8DKS4arkkCLGC=66SUJm5Ugib1EWP7B6MkQRX1k-yd3WBw@mail.gmail.com>
<CANEZrP3v=ySS4gragaWuBMWi_swocRRRq_kw2edo6+9kifgrFQ@mail.gmail.com>
<54D3D636.1030308@voskuil.org>
<CANEZrP3ekWQWeV=Yw_E=n0grORBLHaXLUh3w0EFQdz=HsjWvZw@mail.gmail.com>
<279489A5-1E46-48A2-8F58-1A25821D4D96@gmail.com>
<CANEZrP3VAWajxE=mNxb6sLSQbhaQHD=2TgRKvYrEax2PAzCi2A@mail.gmail.com>
<6AEDF3C4-DEE0-4E31-83D0-4FD92B125452@voskuil.org>
<CABdy8DLRGyy5dvmVb_B3vao7Qwz-zdAC3-+2nJkg9rSsU6FLbw@mail.gmail.com>
<C28CD881-DAB8-4EDB-B239-7D45A825EAF0@voskuil.org>
<54D3FB4A.9010105@voskuil.org>
<CALkkCJammCvVd6_1SYRvnxsMVj_x1AvS1VsSa6_76d0NWMDs=Q@mail.gmail.com>
<54D400F0.9090406@voskuil.org>
<CEB250A3-9014-4AF3-AEB7-E78BE19BF2F5@airbitz.co>
In-Reply-To: <CEB250A3-9014-4AF3-AEB7-E78BE19BF2F5@airbitz.co>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="Lsb3jF9cU2pgAd3eUAHACN4q7xAU1RnPr"
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: 1YJXMA-0004I2-Am
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE)
transfer of Payment URI
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: Fri, 06 Feb 2015 01:05:15 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Lsb3jF9cU2pgAd3eUAHACN4q7xAU1RnPr
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On 02/05/2015 04:49 PM, Paul Puey wrote:
> The trust can be considered bootstrapped by visual verification of the
> address prefix.
Another (unspendable) address can trivially match the prefix. Imagine
someone walking around in a mall with a phone in the pocket with a
malicious app, just disrupting business by causing money to be burned.
Manual verification doesn't fix this attack.
> If we are really concerned about someone jamming a Bluetooth signal
> in a coffeeshop then the UI can encourage verification of the prefix.
I don't think it would be great to constrain a standard implementation
to low cost purchases or the need for manual verification, but again
manual prefix verification isn't actually a solution.
> Much like how regular Bluetooth requires 'pairing' via entering a 4-6
> digit code.
An appeal to the security of BT bootstrapping isn't exactly flattering.
You know I love Airbitz, and I know you guys are extremely privacy
conscious. I personally would have no problem using this feature under
certain circumstances. My question is only whether it would be wise to
standardize on the proposal as-is.
e
> On Feb 5, 2015, at 3:46 PM, Eric Voskuil <eric@voskuil.org
> <mailto:eric@voskuil.org>> wrote:
>=20
> On 02/05/2015 03:36 PM, M=E2=92=B6rtin H=E2=92=B6bo=E2=93=8B=C5=A1tiak =
wrote:
>>> A BIP-70 signed payment request in the initial broadcast can resolve =
the
>>> integrity issues, but because of the public nature of the broadcast
>>> coupled with strong public identity, the privacy compromise is much
>>> worse. Now transactions are cryptographically tainted.
>>>
>>> This is also the problem with BIP-70 over the web. TLS and other
>>> security precautions aside, an interloper on the communication, deskt=
op,
>>> datacenter, etc., can capture payment requests and strongly correlate=
>>> transactions to identities in an automated manner. The payment reques=
t
>>> must be kept private between the parties, and that's hard to do.
>>
>> What about using encryption with forward secrecy? Merchant would
>> generate signed request containing public ECDH part, buyer would send
>> back transaction encrypted with ECDH and his public ECDH part. If
>> receiving address/amount is meant to be private, use commit protocol
>> (see ZRTP/RedPhone) and short authentication phrase (which is hard to
>> spoof thanks to commit protocol - see RedPhone)?
>=20
> Hi Martin,
>=20
> The problem is that you need to verify the ownership of the public key.=
> A MITM can substitute the key. If you don't have verifiable identity
> associated with the public key (PKI/WoT), you need a shared secret (suc=
h
> as a secret phrase). But the problem is then establishing that secret
> over a public channel.
>=20
> You can bootstrap a private session over the untrusted network using a
> trusted public key (PKI/WoT). But the presumption is that you are
> already doing this over the web (using TLS). That process is subject to=
> attack at the CA. WoT is not subject to a CA attack, because it's
> decentralized. But it's also not sufficiently deployed for some scenari=
os.
>=20
> e
>=20
--Lsb3jF9cU2pgAd3eUAHACN4q7xAU1RnPr
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
iQEcBAEBAgAGBQJU1BNTAAoJEDzYwH8LXOFO9qUH/jQhmtYnPF6X+BMhtpPSUDwT
V374DGrF2ZFp1Y49pZlkhhH2b/v31Q0jguTVdwQBULJ/OBpgZQCHfeRT7bbT2QVB
TiAtkAcOhv3c3ymIifKbE7qJT+pbtWJDNyHHvVcfGhKM7NoKmuQZVrzWmJt8F/YD
8KnU1WROp/z4UCeRtd3bM1Zi/KuKuRl1uTX0jG0ZwBXhqU1jX6QUE4b1qvpSgyYr
LhA+H+oxKnx0HGJuDKl4b5yoJHe2ks6hbfoYbTS0/z7K9Hkbs/KsIShIWAg5+Y0o
6QaTMBfofBo0+eTChotWoADC3BpKu99Xl4EBPT3EqeWkCXfbiTx4UaRCWxr8aKw=
=+LwQ
-----END PGP SIGNATURE-----
--Lsb3jF9cU2pgAd3eUAHACN4q7xAU1RnPr--
|
