public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Paul Puey <paul@airbitz•co>
To: Eric Voskuil <eric@voskuil•org>, William Swanson <william@airbitz•co>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
Date: Thu, 5 Feb 2015 16:49:12 -0800	[thread overview]
Message-ID: <CEB250A3-9014-4AF3-AEB7-E78BE19BF2F5@airbitz.co> (raw)
In-Reply-To: <54D400F0.9090406@voskuil.org>

[-- Attachment #1: Type: text/plain, Size: 2296 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 6985 bytes --]

  parent reply	other threads:[~2015-02-06  1:20 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
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 [this message]
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=CEB250A3-9014-4AF3-AEB7-E78BE19BF2F5@airbitz.co \
    --to=paul@airbitz$(echo .)co \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=eric@voskuil$(echo .)org \
    --cc=william@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