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 1WQhak-0001AI-MA for bitcoin-development@lists.sourceforge.net; Thu, 20 Mar 2014 18:21:22 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.169 as permitted sender) client-ip=209.85.220.169; envelope-from=alexy.kot.all@gmail.com; helo=mail-vc0-f169.google.com; Received: from mail-vc0-f169.google.com ([209.85.220.169]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WQhaj-0005wk-Kl for bitcoin-development@lists.sourceforge.net; Thu, 20 Mar 2014 18:21:22 +0000 Received: by mail-vc0-f169.google.com with SMTP id ik5so1456356vcb.0 for ; Thu, 20 Mar 2014 11:21:16 -0700 (PDT) X-Received: by 10.58.54.35 with SMTP id g3mr1636446vep.46.1395339676121; Thu, 20 Mar 2014 11:21:16 -0700 (PDT) MIME-Version: 1.0 Sender: alexy.kot.all@gmail.com Received: by 10.59.0.38 with HTTP; Thu, 20 Mar 2014 11:20:36 -0700 (PDT) In-Reply-To: References: From: Alex Kotenko Date: Thu, 20 Mar 2014 18:20:36 +0000 X-Google-Sender-Auth: -m6hFOxY7R3O_prpeF-jIGCdjKc Message-ID: To: Mike Hearn Content-Type: multipart/alternative; boundary=089e013cbcb4bc800304f50dd515 X-Spam-Score: -0.6 (/) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (alexy.kot.all[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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 X-Headers-End: 1WQhaj-0005wk-Kl Cc: Bitcoin Dev , Andreas Schildbach Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 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, 20 Mar 2014 18:21:22 -0000 --089e013cbcb4bc800304f50dd515 Content-Type: text/plain; charset=UTF-8 Hmm, is there any other way to do it? Can we provide a signed payment request and verify the sign on receiving side and this way protect from bluetooth MitM attack? Quick googling showed that SSL over bluetooth isn't a very well developed area, and my own skills are not enough to quickly implement a reliable secure solution here. 2014-03-20 10:36 GMT+00:00 Mike Hearn : > Encoding entire payment requests into qrcodes is definitely not the way to > go. They can already be large when signed and we're just at the start of > adding features. > > Finishing off and standardising the bluetooth support is the way to go > (r=bt:mac). Andreas' app already has some support for this I believe, so > Alex you could prototype with that, but we need to: > > 1) Add an encryption/auth layer on top, because it runs over RFCOMM > sockets. The authentication would require proof of owning the Bitcoin key > that's in the address part of the URI (which is needed for backwards compat > anyway). > > 2) Write a BIP for it and make sure it's interoperable > > For the auth layer we could either use SSL and then just ignore the server > certificate and require signing of the session public key with the Bitcoin > key, which should be easy to code up but is rather heavy on the air, or > roll a custom lightweight thing where we just do a basic ECDH, with the > servers key being the same as the address key. But rolling such protocols > is subtle and I guess it'd need to be reviewed by people familiar with such > things. > > This feels like a good opportunity to grow the community - perhaps we can > find a volunteer in the forums who enjoys crypto. > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --089e013cbcb4bc800304f50dd515 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hmm, is there any other way to do it? Can we p= rovide a signed payment request and verify the sign on receiving side and t= his way protect from bluetooth MitM attack? Quick googling showed that SSL = over bluetooth isn't a very well developed area, and my own skills are = not enough to quickly implement a reliable secure solution here.


<= div class=3D"gmail_extra">
2014-03-20 10:36 GMT+0= 0:00 Mike Hearn <mike@plan99.net>:
= Encoding entire payment requests into qrcodes is definitely not the way to = go. They can already be large when signed and we're just at the start o= f adding features.

Finishing off and standardising the bl= uetooth support is the way to go (r=3Dbt:mac). Andreas' app already has= some support for this I believe, so Alex you could prototype with that, bu= t we need to:

1) Add an e= ncryption/auth layer on top, because it runs over RFCOMM sockets. The authe= ntication would require proof of owning the Bitcoin key that's in the a= ddress part of the URI (which is needed for backwards compat anyway).

2) Write a = BIP for it and make sure it's interoperable

For the auth layer we could eithe= r use SSL and then just ignore the server certificate and require signing o= f the session public key with the Bitcoin key, which should be easy to code= up but is rather heavy on the air, or roll a custom lightweight thing wher= e we just do a basic ECDH, with the servers key being the same as the addre= ss key. But rolling such protocols is subtle and I guess it'd need to b= e reviewed by people familiar with such things.

This feels = like a good opportunity to grow the community - perhaps we can find a volun= teer in the forums who enjoys crypto.

-----------------------------------------------------------------------= -------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases = and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf= .net/sfu/13534_NeoTech
_____________________________________________= __
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--089e013cbcb4bc800304f50dd515--