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; 
MIME-Version: 1.0
Sender: alexy.kot.all@gmail.com
In-Reply-To: <CANEZrP0J849oDvMWjf8LWi0xj44Q8DaUwDip5_smVBMNgeQ3mw@mail.gmail.com>
References: <lc5hmg$1jh$1@ger.gmane.org> <leuunm$tjk$1@ger.gmane.org>
	<CANEZrP3nQfvDArKTRgje0Cus4G2JD_zpxSjA3fXfxM2TNAP80Q@mail.gmail.com>
	<CALDj+BafD+6KTNcYDBEu5gNPzYozSkiC-JCxrY-PzXL2DYBRsw@mail.gmail.com>
	<CAJHLa0N4J_Z907+D0ENSNKfNAW2N=7Jf4JzSCO=SU558GtGTzA@mail.gmail.com>
	<lge7nk$3mf$2@ger.gmane.org>
	<CANEZrP0J849oDvMWjf8LWi0xj44Q8DaUwDip5_smVBMNgeQ3mw@mail.gmail.com>
From: Alex Kotenko <alexykot@gmail.com>
Date: Thu, 20 Mar 2014 18:20:36 +0000
Message-ID: <CALDj+BZJ0rSKuDHdbL7ANN0Vtaa3-KGYgusqMDzzB-CUxjMz7g@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=089e013cbcb4bc800304f50dd515
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Precedence: list

--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 <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 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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:courier =
new,monospace;color:#003300">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&#39;t a very well developed area, and my own skills are =
not enough to quickly implement a reliable secure solution here.</div>

<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra"><div class=3D"gmail_quote">2014-03-20 10:36 GMT+0=
0:00 Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"mailto:mike@plan99.net" ta=
rget=3D"_blank">mike@plan99.net</a>&gt;</span>:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
Encoding entire payment requests into qrcodes is definitely not the way to =
go. They can already be large when signed and we&#39;re just at the start o=
f adding features.</div>

<div class=3D"gmail_extra">
<br></div><div class=3D"gmail_extra">Finishing off and standardising the bl=
uetooth support is the way to go (r=3Dbt:mac). Andreas&#39; app already has=
 some support for this I believe, so Alex you could prototype with that, bu=
t we need to:</div>


<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">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&#39;s in the a=
ddress part of the URI (which is needed for backwards compat anyway).</div>


<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">2) Write a =
BIP for it and make sure it&#39;s interoperable</div><div class=3D"gmail_ex=
tra"><br></div><div class=3D"gmail_extra">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&#39;d need to b=
e reviewed by people familiar with such things.</div>


<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">This feels =
like a good opportunity to grow the community - perhaps we can find a volun=
teer in the forums who enjoys crypto.</div></div>
<br>-----------------------------------------------------------------------=
-------<br>
Learn Graph Databases - Download FREE O&#39;Reilly Book<br>
&quot;Graph Databases&quot; is the definitive new guide to graph databases =
and their<br>
applications. Written by three acclaimed leaders in the field,<br>
this first edition is now available. Download your free book today!<br>
<a href=3D"http://p.sf.net/sfu/13534_NeoTech" target=3D"_blank">http://p.sf=
.net/sfu/13534_NeoTech</a><br>_____________________________________________=
__<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div>

--089e013cbcb4bc800304f50dd515--