From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YJW8G-00039T-QZ for bitcoin-development@lists.sourceforge.net; Thu, 05 Feb 2015 23:46:48 +0000 X-ACL-Warn: Received: from mail-pa0-f46.google.com ([209.85.220.46]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YJW8F-00021m-S7 for bitcoin-development@lists.sourceforge.net; Thu, 05 Feb 2015 23:46:48 +0000 Received: by mail-pa0-f46.google.com with SMTP id lj1so13155970pab.5 for ; Thu, 05 Feb 2015 15:46:42 -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=cu919z/gLKLEBbCC+3bOu2DRfSOTs6ZSKFRKZTKFqdo=; b=cV3LWJqnmTTqrYwDyNiOwKLi8yvbdmYHOIyaPcrH8HD2sWwIXJKVz9KSEPQqb8iaI/ x3kv3WamGEzdAjiMYsOeyV+CNScO6HA/vRWNh2vM/wb0RYt6Zc9jHNXow2zCrH0nJ83g arFGudo6dDTAfdmwikIp6/PyhceQK7pgFNHepWU6JO9SMHrWgoBUzlFZ6YOYF9NhcMQ7 lTdf8elU7O3D+J51lS26Xdp9xgu1BiHXzv5xjUcbWKuyrSWMmFvSYZvT2vi+lL88Irm6 /vrpIICbhWlcRMP4zxKQqZLY85m6eTMdaVE3jlW9WSaA2nSvBUHgOm3A/WrjPt/WjBXM wHbw== X-Gm-Message-State: ALoCoQkXmXZy9O6Rv/oFeoMbwuApVOPd9sWdNhkKdzgZLkqQaQEfkcbbmcLkgqWKm430ttOZv7HB X-Received: by 10.70.135.165 with SMTP id pt5mr1027571pdb.101.1423180002084; Thu, 05 Feb 2015 15:46:42 -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 o3sm6154062pde.7.2015.02.05.15.46.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Feb 2015 15:46:41 -0800 (PST) Message-ID: <54D400F0.9090406@voskuil.org> Date: Thu, 05 Feb 2015 15:46:56 -0800 From: Eric Voskuil 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?= References: <54D3D636.1030308@voskuil.org> <279489A5-1E46-48A2-8F58-1A25821D4D96@gmail.com> <6AEDF3C4-DEE0-4E31-83D0-4FD92B125452@voskuil.org> <54D3FB4A.9010105@voskuil.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mUHfk0U7m1ieLkpjNDIjgXpavliLvK60X" 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: 1YJW8F-00021m-S7 Cc: Bitcoin Dev , Paul Puey 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 23:46:48 -0000 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--