Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

["Martin Habovštiak" <martin.habovstiak@gmail.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Commit protocol provides both better user experience and better security.

Dňa 6. februára 2015 1:49:12 CET používateľ Paul Puey <paul@airbitz.co> napísal:
>The trust can be considered bootstrapped by visual verification of the
>address prefix. If we are really concerned about someone jamming a
>Bluetooth signal in a coffeeshop then the UI can encourage verification
>of the prefix. Much like how regular Bluetooth requires 'pairing' via
>entering a 4-6 digit code.
>
>
>
>Paul Puey CEO / Co-Founder, Airbitz Inc
>619.850.8624 | http://airbitz.co | San Diego
>
>
>
>
>On Feb 5, 2015, at 3:46 PM, Eric Voskuil <eric@voskuil.org> wrote:
>
>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

- --
Odoslané z môjho Android zariadenia pomocou K-9 Mail.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iI8EAREKADcFAlTUD/AwHE1hcnRpbiBIYWJvdmF0aWFrIDxtYXJ0aW4uaGFib3Zz
dGlha0BnbWFpbC5jb20+AAoJED6C3NvqapyUPwgA/0eVlJYeA3fYmVb1zVA8j1l/
kjOhc9CIDYL9ifk8N0t/AP4mC4CwmZoNXqr24le5WdYeBeyHMiDMtJrRfwQkN1LG
dQ==
=pY76
-----END PGP SIGNATURE-----