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 1YJXbB-0006Jz-3o for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 01:20:45 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of airbitz.co designates 209.85.192.169 as permitted sender) client-ip=209.85.192.169; envelope-from=paul@airbitz.co; helo=mail-pd0-f169.google.com; Received: from mail-pd0-f169.google.com ([209.85.192.169]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YJXb6-0004hE-GH for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 01:20:45 +0000 Received: by pdiy13 with SMTP id y13so11245221pdi.8 for ; Thu, 05 Feb 2015 17:20:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=8h7wSfe45hMzuqnOPr812+hyMF81aBaYx9woDFVmuok=; b=Q1dENF9Mwtr9SaaIV3x++bHkdghTkF4e6DEhEFFu3FS5+8ywt/YMsTk4Ow1FrImRgr 0iTo+4aNiR0KUiLfLicma1RiB63VhaI3C+8vxRMs4TqIMCRc5mKrZOnD3UNJzu5FJyFz Nhss4BOgJp2+uhaHXOUeZ64dfRMgL7ZyX/BMDMQk1vAzP7gLw1hLZEaLHnc9zcTCwHRv mDAwOk1F14jhHEiH7RBKnvqZkxXIsgyv5k6DSypYfWMmCwHndyqdOqWd3NTL5u9/FAOT B1M+GNUIunBQmWPBChBJtHFPKZ/HRR9otRAxz72BwGOWHAPz2AWqBkSawPQDQAN1i4Xe 1XpQ== X-Gm-Message-State: ALoCoQknXnPGEn3KO1HiSOgMXalq+bJ5QlZrPzRLyP0ncNUr77Hs8lieURxpMI2TnYKueySgI+ey X-Received: by 10.66.138.72 with SMTP id qo8mr1453940pab.84.1423183756748; Thu, 05 Feb 2015 16:49:16 -0800 (PST) Received: from [10.204.163.123] (mobile-166-171-251-007.mycingular.net. [166.171.251.7]) by mx.google.com with ESMTPSA id f5sm6231559pdm.3.2015.02.05.16.49.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 16:49:14 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-278FFE3E-4FC7-444B-B156-08D866B143A6 Mime-Version: 1.0 (1.0) From: Paul Puey X-Mailer: iPhone Mail (12B411) In-Reply-To: <54D400F0.9090406@voskuil.org> Date: Thu, 5 Feb 2015 16:49:12 -0800 Content-Transfer-Encoding: 7bit Message-Id: 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> To: Eric Voskuil , William Swanson X-Spam-Score: -0.3 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.3 HTML_FONT_FACE_BAD BODY: HTML font face is not a word 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 T_REMOTE_IMAGE Message contains an external image X-Headers-End: 1YJXb6-0004hE-GH 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:20:45 -0000 --Apple-Mail-278FFE3E-4FC7-444B-B156-08D866B143A6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The trust can be considered bootstrapped by visual verification of the addre= ss prefix. If we are really concerned about someone jamming a Bluetooth sign= al in a coffeeshop then the UI can encourage verification of the prefix. Muc= h like how regular Bluetooth requires 'pairing' via entering a 4-6 digit cod= e. =20 Paul Puey CEO / Co-Founder, Airbitz Inc 619.850.8624 | http://airbitz.co | San Diego =20 On Feb 5, 2015, at 3:46 PM, Eric Voskuil wrote: 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. >>=20 >> This is also the problem with BIP-70 over the web. TLS and other >> security precautions aside, an interloper on the communication, desktop, >> 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. e --Apple-Mail-278FFE3E-4FC7-444B-B156-08D866B143A6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The trust can be considered bootstrapp= ed by visual verification of the address prefix. If we are really concerned a= bout someone jamming a Bluetooth signal in a coffeeshop then the UI can enco= urage verification of the prefix. Much like how regular Bluetooth requires '= pairing' via entering a 4-6 digit code.


=
3D"logo"   
619.850.8624 |&= nbsp;http://airbitz.co | San Diego
<= tr valign=3D"top"><= td>


On Feb 5, 2015, at 3:46 PM, E= ric Voskuil <eric@voskuil.org>= wrote:

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 broad= cast can resolve the
integrity issues, but because of the p= ublic nature of the broadcast
coupled with strong public i= dentity, the privacy compromise is much
=
worse. Now transac= tions are cryptographically tainted.

Th= is is also the problem with BIP-70 over the web. TLS and other
<= span>security precautions aside, an interloper on the communication, desktop= ,
datacenter, etc., can capture payment requests and strong= ly correlate
<= blockquote type=3D"cite">transactions to identities in an automated ma= nner. The payment request
must be kept private between the= parties, and that's hard to do.

<= span>What about using encryption with forward secrecy? Merchant would=
generate signed request con= taining public ECDH part, buyer would send
back transaction encrypted with ECDH and his public EC= DH part. If
receiving= address/amount is meant to be private, use commit protocol
(see ZRTP/RedPhone) and short authent= ication phrase (which is hard to
spoof thanks to commit protocol - see RedPhone)?

Hi Martin,

T= he 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 ident= ity
associated with the public key (PKI/WoT), you need a sha= red secret (such
as a secret phrase). But the problem is the= n establishing that secret
over a public channel.
=
You can bootstrap a private session over the untruste= d network using a
trusted public key (PKI/WoT). But the pres= umption is that you are
already doing this over the web (usi= ng 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.

e

= --Apple-Mail-278FFE3E-4FC7-444B-B156-08D866B143A6--