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"
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE)
 transfer of Payment URI
Precedence: list

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