Message-ID: <54D400F0.9090406@voskuil.org>
Date: Thu, 05 Feb 2015 15:46:56 -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: =?UTF-8?B?TeKStnJ0aW4gSOKStmJv4pOLxaF0aWFr?= <martin.habovstiak@gmail.com>
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>
In-Reply-To: <CALkkCJammCvVd6_1SYRvnxsMVj_x1AvS1VsSa6_76d0NWMDs=Q@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="mUHfk0U7m1ieLkpjNDIjgXpavliLvK60X"
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Paul Puey <paul@airbitz.co>
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)
--mUHfk0U7m1ieLkpjNDIjgXpavliLvK60X
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 02/05/2015 03:36 PM, M=E2=92=B6rtin H=E2=92=B6bo=E2=93=8B=C5=A1tiak wr=
ote:
>> A BIP-70 signed payment request in the initial broadcast can resolve t=
he
>> 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, deskto=
p,
>> datacenter, etc., can capture payment requests and strongly correlate
>> transactions to identities in an automated manner. The payment request=

>> must be kept private between the parties, and that's hard to do.
>=20
> 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)?

Hi Martin,

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 (such
as a secret phrase). But the problem is then establishing that secret
over a public channel.

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 scenarios=
=2E

e


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

iQEcBAEBAgAGBQJU1ADwAAoJEDzYwH8LXOFOwrsH/Aouccypuw2Dyqe7FyU8QJhz
a3GH83p46wjMNjq8G4S5hBsMfbIBJqedOVQDce0B7LoJyQwniB9oWaQakI9BP9hO
rTGsIT27ieTo8L74sdK1htIj8kVSdj2baeSMpI/q7LuVQTYBmVtxrRGPnEIsaSMN
gBjg9b006aAFLVSTr2Vqs+J+9nMY8Q5wEfGDPBo3llef3igoZSd5mPq8IkLvsxI2
FyN96iAi/lguVicpUysHoz+V5npvyVx7kYafNFPEp5TSVYg3xc/hZK8/zZFRUznB
3ejAoZQlSGk3ISdH/hH69Sb6dCWl2Wh8n3J2/FDpwI+F0lOXq4MqO02ktmE00WA=
=Iut5
-----END PGP SIGNATURE-----

--mUHfk0U7m1ieLkpjNDIjgXpavliLvK60X--