Message-ID: <54D4093F.5000707@voskuil.org>
Date: Thu, 05 Feb 2015 16:22:23 -0800
From: Eric Voskuil <eric@voskuil.org>
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?= <martin.habovstiak@gmail.com>
References: <CABdy8DKS4arkkCLGC=66SUJm5Ugib1EWP7B6MkQRX1k-yd3WBw@mail.gmail.com>	<CANEZrP3v=ySS4gragaWuBMWi_swocRRRq_kw2edo6+9kifgrFQ@mail.gmail.com>	<54D3D636.1030308@voskuil.org>	<CANEZrP3ekWQWeV=Yw_E=n0grORBLHaXLUh3w0EFQdz=HsjWvZw@mail.gmail.com>	<279489A5-1E46-48A2-8F58-1A25821D4D96@gmail.com>	<CANEZrP3VAWajxE=mNxb6sLSQbhaQHD=2TgRKvYrEax2PAzCi2A@mail.gmail.com>	<6AEDF3C4-DEE0-4E31-83D0-4FD92B125452@voskuil.org>	<CABdy8DLRGyy5dvmVb_B3vao7Qwz-zdAC3-+2nJkg9rSsU6FLbw@mail.gmail.com>	<C28CD881-DAB8-4EDB-B239-7D45A825EAF0@voskuil.org>	<54D3FB4A.9010105@voskuil.org>	<CALkkCJammCvVd6_1SYRvnxsMVj_x1AvS1VsSa6_76d0NWMDs=Q@mail.gmail.com>	<54D400F0.9090406@voskuil.org>
	<CALkkCJYLfEXxvKjOMCNtK3zhCOmO24JD3w73VwORoqX9xF_p7w@mail.gmail.com>
In-Reply-To: <CALkkCJYLfEXxvKjOMCNtK3zhCOmO24JD3w73VwORoqX9xF_p7w@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="TeE7WPtafmTddeI1dUHCKCg636OsGKSoU"
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Paul Puey <paul@airbitz.co>
Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE)
 transfer of Payment URI
Precedence: list

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 <eric@voskuil.org>:
>> 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--