From: Eric Voskuil <eric@voskuil•org>
To: "Martin Habovštiak" <martin.habovstiak@gmail•com>
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
Date: Thu, 05 Feb 2015 17:29:03 -0800 [thread overview]
Message-ID: <54D418DF.1000704@voskuil.org> (raw)
In-Reply-To: <C6292B5F-B48D-4BCE-909E-DD59261E8E95@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6187 bytes --]
On 02/05/2015 04:36 PM, Martin Habovštiak 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ňa 6. februára 2015 1:22:23 CET používateľ Eric Voskuil
<eric@voskuil•org> napísal:
>> On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak 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. :)
>
>> 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
>> channel?
>
>>> 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.
>
>> 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Ⓐrtin HⒶboⓋštiak 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
>>>>
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-02-06 1:28 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-05 20:06 Paul Puey
2015-02-05 20:28 ` Mike Hearn
2015-02-05 20:37 ` Paul Puey
2015-02-05 20:43 ` Mike Hearn
2015-02-05 20:44 ` Eric Voskuil
2015-02-05 20:50 ` Mike Hearn
2015-02-05 20:59 ` Eric Voskuil
2015-02-05 21:19 ` Brian Hoffman
2015-02-05 21:23 ` Eric Voskuil
2015-02-05 21:36 ` Mike Hearn
2015-02-05 21:46 ` Eric Voskuil
2015-02-05 22:07 ` Paul Puey
2015-02-05 22:10 ` Eric Voskuil
2015-02-05 22:49 ` Roy Badami
2015-02-05 23:22 ` MⒶrtin HⒶboⓋštiak
2015-02-05 23:02 ` William Swanson
2015-02-05 23:34 ` Roy Badami
2015-02-05 23:59 ` Eric Voskuil
2015-02-06 8:59 ` Roy Badami
2015-02-06 9:13 ` Eric Voskuil
2015-02-06 0:58 ` Paul Puey
2015-02-05 23:22 ` Eric Voskuil
2015-02-05 23:36 ` MⒶrtin HⒶboⓋštiak
2015-02-05 23:46 ` Eric Voskuil
2015-02-06 0:04 ` MⒶrtin HⒶboⓋštiak
2015-02-06 0:22 ` Eric Voskuil
2015-02-06 0:36 ` Martin Habovštiak
2015-02-06 1:29 ` Eric Voskuil [this message]
2015-02-06 9:07 ` MⒶrtin HⒶboⓋštiak
2015-02-10 16:55 ` Eric Voskuil
2015-02-10 17:16 ` MⒶrtin HⒶboⓋštiak
2015-02-10 17:56 ` Eric Voskuil
2015-02-06 0:49 ` Paul Puey
2015-02-06 0:50 ` Martin Habovštiak
2015-02-06 1:05 ` Eric Voskuil
2015-02-06 2:09 ` Paul Puey
2015-02-05 22:02 ` Paul Puey
2015-02-05 22:01 ` Paul Puey
2015-02-05 22:05 ` Eric Voskuil
2015-02-05 22:08 ` Paul Puey
-- strict thread matches above, loose matches on Subject: below --
2015-02-05 8:01 Paul Puey
2015-02-05 13:46 ` Andreas Schildbach
2015-02-05 13:57 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54D418DF.1000704@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=martin.habovstiak@gmail$(echo .)com \
--cc=paul@airbitz$(echo .)co \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox