From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YJXj6-0000yn-3y for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 01:28:56 +0000 X-ACL-Warn: Received: from mail-pd0-f174.google.com ([209.85.192.174]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YJXj3-0005FY-Qb for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 01:28:56 +0000 Received: by pdbfl12 with SMTP id fl12so1243354pdb.10 for ; Thu, 05 Feb 2015 17:28:48 -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=unQG3v1dqyyk4dxnUP7/+I9y4RQ83bAPDfkkUeXob5I=; b=Cv9DI/A78NZoXcT41TI+9Y68DYBXA9KM/Q+hus8KthJq86JUL4stIjJ9l99AQ4AbFs jrQ6MFVtbAetXK35fwAjJx81UmyMJ6yf5Q0aNfJc8m6gVC5xN3fT1fWb1TuGwGGO1ujo HPluAVoyF2pu13vMnAkQYf+q45RnKrMr5JAW/kCpFX5xSOYzukKpp/eeVGWtTPvGyfyK vZ+XQSYyAz6fcuSGbAl9ZMX7mv5WnrhOEpXZ+jNOAenbyPCEIE9pKudDsO1eYT4b2TxA esIFhi489r+53U8nnmZmUAFtZZ4hXlHAMEZFi3u2EkQiyS+xdVnZ09/MxM+32WKSDTLI T41A== X-Gm-Message-State: ALoCoQmoGt91Zebsl5Pw78BJc9QidyyOf+7c3PNETX55Yd4IhLHO3i9fWVFmb/itIAoHunYHRuN+ X-Received: by 10.70.91.81 with SMTP id cc17mr1660326pdb.150.1423186128183; Thu, 05 Feb 2015 17:28:48 -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 v2sm6234837pdm.77.2015.02.05.17.28.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Feb 2015 17:28:47 -0800 (PST) Message-ID: <54D418DF.1000704@voskuil.org> Date: Thu, 05 Feb 2015 17:29:03 -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?TWFydGluIEhhYm92xaF0aWFr?= 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> <54D4093F.5000707@voskuil.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Wp147wGp2dfxsL9c5cLqmKS1iIkb1037e" 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: 1YJXj3-0005FY-Qb 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: Fri, 06 Feb 2015 01:28:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Wp147wGp2dfxsL9c5cLqmKS1iIkb1037e Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/05/2015 04:36 PM, Martin Habov=C5=A1tiak wrote: > I believe, we are still talking about transactions of physical > people in physical world. So yes, it's proximity based - people > tell the words by mouth. :) Notice from my original comment: >>>> 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). I said this could only be accomplished using a shared secret or a trusted public key. Exchanging a value that is derived from a pair of public keys is a distinction without a difference. The problem remains that the parties must have a secure/out-of-band channel for communicating this value. The fact that they are face-to-face establishes this channel, but that brings us back to the original problem, as it requires manual verification - as in visual/audible scanning of the two values for comparison. At that point the visual comparison of the address, or some value derived from it, is simpler. > In case of RedPhone, you read those words verbally over not-yet- > verified channel relying on difficulty of spoofing your voice. Also > the app remembers the public keys, so you don't need to verify > second time. This is reasonable, but wouldn't help in the case of an ad-hoc connection between parties who don't know each other well. > I suggest you to try RedPhone (called Signal on iPhone) yourself. > It's free/open source, Internet-based and end-to-end encrypted. You > may find it useful some day. Also I'm willing to help you with > trying it after I wake up. (~8 hours: Send me private e-mail if > you want to.) I appreciate the offer. I really don't trust *any* smartphone as a platform for secure communication/data. But encrypting on the wire does of course shrink the attack surface and increase the attacker's cost. e > D=C5=88a 6. febru=C3=A1ra 2015 1:22:23 CET pou=C5=BE=C3=ADvate=C4=BE Er= ic Voskuil nap=C3=ADsal: >> On 02/05/2015 04:04 PM, M=E2=92=B6rtin H=E2=92=B6bo=E2=93=8B=C5=A1tiak= wrote: >>> That's exactly what I though when seeing the RedPhone code, but after= >>> I studied the commit protocol I realized it's actually secure and >>> convenient way to do it. You should do that too. :) >=20 >> I was analyzing the model as you described it to me. A formal analysis= >> of the security model of a particular implementation, based on >> inference >>from source code, is a bit beyond what I signed up for. But I'm >> perfectly willing to comment on your description of the model if you >> are >> willing to indulge me. >=20 >>> Shortly, how it works: >>> The initiator of the connection sends commit message containing the >>> hash of his temporary public ECDH part, second party sends back their= >>> public ECDH part and then initiator sends his public ECDH part in >>> open. All three messages are hashed together and the first two bytes >>> are used to select two words from a shared dictionary which are >>> displayed on the screen of both the initiator and the second party. >=20 >>> The parties communicate those two words and verify they match. >=20 >> How do they compare words if they haven't yet established a secure >> channel? >=20 >>> If an attacker wants to do MITM, he has a chance of choosing right >>> public parts 1:65536. There is no way to brute-force it, since that >>> would be noticed immediately. If instead of two words based on the >>> first two bytes, four words from BIP39 wordlist were chosen, it would= >>> provide entropy of 44 bits which I believe should be enough even for >>> paranoid people. >>> >>> How this would work in Bitcoin payment scenario: user's phone >>> broadcasts his name, merchant inputs amount and selects the name from= >>> the list, commit message is sent (and then the remaining two >>> messages), merchant spells four words he sees on the screen and buyer= >>> confirms transaction after verifying that words match. >=20 >> So the assumption is that there exists a secure (as in proximity-based= ) >> communication channel? >=20 >> e >=20 >>> 2015-02-06 0:46 GMT+01:00 Eric Voskuil : >>>> On 02/05/2015 03:36 PM, M=E2=92=B6rtin H=E2=92=B6bo=E2=93=8B=C5=A1ti= ak 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, >> 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. >>>>> >>>>> 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 >>>> >=20 >=20 --Wp147wGp2dfxsL9c5cLqmKS1iIkb1037e 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 iQEcBAEBAgAGBQJU1BjfAAoJEDzYwH8LXOFOkvYIAIIPM+8PCUG13MzqP5ycPvEl uL3fAeC4+8+waF9wuq2sJ0LMOBHQNqhKYk+6/qoGRHD5TOljvYcvD84UNww8nYl1 gWnI9CXRAWqLXjKMw2HKKge53cXNp0Z2//6sfgQlgODMRisG2dqpxicagHtvBsp+ nQaVsPuwL6lXI2q/lYga7ke9Olc5Wo7Ot9D522XYY5RT5ijWx1ttyk3kBinTfyiI Nto5IKtxNWeJHNbKStNh/rQHuHwayl2GN4RX6NSEzlLDc5QaLerzYE0YClUfyqWL aQ/mRy0nCPVq4Ik7ewRc76hecWWGPdrDj4zOVrezJP1R5bwvAQOWyDIBMs3/n/M= =B8C8 -----END PGP SIGNATURE----- --Wp147wGp2dfxsL9c5cLqmKS1iIkb1037e--