From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YJWgZ-0007Mw-3L for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 00:22:15 +0000 X-ACL-Warn: Received: from mail-pa0-f52.google.com ([209.85.220.52]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YJWgX-0003ac-Pn for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 00:22:15 +0000 Received: by mail-pa0-f52.google.com with SMTP id kq14so5782172pab.11 for ; Thu, 05 Feb 2015 16:22: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=wNC4jRpJX7Irrbw4dZ/RdJ4lHgJ8tWahIWnBavBQ6vY=; b=ct4Km64Yg7aD/hDitJWk8C8qBrxf7I6MgOoETp9/0AQjTdY2l1fwD41XzddxfWLZr7 1a4EdZZdYaJG6YAYWJQSO+9+FiJ/H7ze/4l+FiT+HuTWxDJCu31P62r3eGqWS++B4mtB fHsYkeJ/K27ASeyMQGDGVnOCv8dkWm/OStlxVCF/8rGeohuUCuplQ4+42+INNItMuKsm Kw1GHVtjvK5M7rff7HDEGqBn9otuoky+4oAXFCOL022z+/FoUpb0mMrPHZKqES8WlU3v zQCUxXsDOk1DjRQsX9I2Dqx6jcwf/9P8Xv10Mbj1J6GXP5r8u5UFq4sUBE+F4RQlu4yj hrEQ== X-Gm-Message-State: ALoCoQm9Yl1oyjt5w9v3TLhj7VicnOpZmH1/pixASq2E6WtyYx8IWi9OG5d7+R1mhUt1KP+/7RDn X-Received: by 10.68.231.102 with SMTP id tf6mr1300734pbc.40.1423182128081; Thu, 05 Feb 2015 16:22: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 r7sm6145955pdn.87.2015.02.05.16.22.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Feb 2015 16:22:07 -0800 (PST) Message-ID: <54D4093F.5000707@voskuil.org> Date: Thu, 05 Feb 2015 16:22: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: =?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> <54D400F0.9090406@voskuil.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TeE7WPtafmTddeI1dUHCKCg636OsGKSoU" 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: 1YJWgX-0003ac-Pn 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 00:22:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TeE7WPtafmTddeI1dUHCKCg636OsGKSoU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/05/2015 04:04 PM, M=E2=92=B6rtin H=E2=92=B6bo=E2=93=8B=C5=A1tiak wr= ote: > 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. :) 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. > 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. > The parties communicate those two words and verify they match. How do they compare words if they haven't yet established a secure channe= l? > 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. >=20 > 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. So the assumption is that there exists a secure (as in proximity-based) communication channel? e > 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=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, desk= top, >>>> datacenter, etc., can capture payment requests and strongly correlat= e >>>> transactions to identities in an automated manner. The payment reque= st >>>> 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= =2E >> 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 (su= ch >> 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 t= o >> 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 scenar= ios. >> >> e >> --TeE7WPtafmTddeI1dUHCKCg636OsGKSoU 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 iQEcBAEBAgAGBQJU1Ak/AAoJEDzYwH8LXOFOTtEH/3ZinXCIXzqZi7khNziLXvoV Eyf0mQoWRi5sXZOez8bJjbB+b1xVfti6SSJht1UyAcB+xVk7pi29VEsIIhq5mppg OtY7MBAmpIvr7xaVyGXOxi0amCk295VONc/6xTGoElVkADx1HsnGOWEbCYRBvrk0 RlmZpkjWwK/X8g2Zg2P57yMhp6bcQ53bCtMYr6YCC/XxHdn76QI843vUitWVo6Fh NRsSnTL5oCUHsJNq0glfp0VjcFP5P6XD2J9zX/3FxvIoretLZcspNFksN85gQkg/ Tx01p6dTEkytkuvCuDyZGI7JVdJXIxPQSzvNo7KQ2SssArg3QIR6LwD3ebmVjVM= =+oYC -----END PGP SIGNATURE----- --TeE7WPtafmTddeI1dUHCKCg636OsGKSoU--