path: root/35/98bc3f13e5dc16e6142183e0dd10ccbde92ca8

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 <eric@voskuil.org>) 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 <bitcoin-development@lists.sourceforge.net>;
	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 <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?TWFydGluIEhhYm92xaF0aWFr?= <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>
	<54D4093F.5000707@voskuil.org>
	<C6292B5F-B48D-4BCE-909E-DD59261E8E95@gmail.com>
In-Reply-To: <C6292B5F-B48D-4BCE-909E-DD59261E8E95@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>,
	Paul Puey <paul@airbitz.co>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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
<eric@voskuil.org> 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 <eric@voskuil.org>:
>>>> 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--