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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) 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 ; 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 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 , William Swanson References: <54D3D636.1030308@voskuil.org> <279489A5-1E46-48A2-8F58-1A25821D4D96@gmail.com> <6AEDF3C4-DEE0-4E31-83D0-4FD92B125452@voskuil.org> <54D3FB4A.9010105@voskuil.org> <54D400F0.9090406@voskuil.org> In-Reply-To: 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 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: 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 > 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--