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

2015-02-10 Thread Eric Voskuil
Martin,

I like your idea for the commit protocol in that it resolves the
vandalous address substitution attack. However, I don't see a way to
prevent privacy loss without adverse impact to the scenario.

Anyone could perform the handshake and thereby obtain the payment
request. Therefore to prevent inadvertent disclosure the customer must
visually confirm the phrase and then verbally tell the merchant to
proceed by sending the payment request.

One might argue that it's sufficient to preserve the integrity of the
transaction while suffering the privacy loss, especially given that a
hijacked handshake should never result in a completed transaction -
unless of course the hijacker pays.

But imagine someone purchasing their meds. HIPAA requires the checkout
queue to form behind a yellow line. That speaks directly to this question.

e

On 02/06/2015 01:07 AM, MⒶrtin HⒶboⓋštiak wrote:
 2015-02-06 2:29 GMT+01:00 Eric Voskuil e...@voskuil.org:
 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.
 
 I have never been against manual verification. What I'm trying to say
 is let's just make manual verification easier and more secure.
 Comparison of address is simpler for the coder but also simpler to
 attack. It has these problems:
 - Addresses broadcasted in plaintext (privacy issue)
 - Amounts broadcasted in plaintext (privacy issue)
 - Address is long - takes lot of time to verify (user experience issue)
 - Address prefix can be brute-forced, if too short or used to make
 black hole address if longer (vandalism issue)
 
 Commit protocol can be used for both the encryption and the
 authentication while user experience is not bad and everything is
 still secure.
 

 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
 e...@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 

[Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

2015-02-10 Thread Natanael
BIP70 is a protocol for getting a user's wallet client communicate with a
merchant's server in order to agree on details like where to send the
payment, how much to send, what the shipping address is, sending a receipt
back, and much more using various extensions that adds more functionality.

There could even be advanced functionality for automatically negotiating
terms. One example could be selecting a multisignature arbitrator both
sides trust. Another could be to agree on the speed and type of delivery.
Many more types of decisions could be automatically agreed upon.

But as it is now, it is designed to be initiated at the time of payment. If
you always want next-day delivery from online stores then you won't always
know if that's an option until you've filled the digital basket and gone
through checkout. If you only want to shop with an arbitrator involved same
thing applies.

Everything that BIP70 enables happens at the last step only, as it is right
now.

If there could be a BIP70 HTML tag on web shops that automatically
triggered your wallet as soon as you visit the page, it would be possible
for a browser extension that talks to your wallet to tell you right away if
the web shop you're currently looking at has terms you consider acceptable
or not (note: if your wallet client isn't installed on or linked to that
same machine, a visible Qr code would be an acceptable alternative which
you can scan in advance before you start shopping). This notification can
even be automatically updated as you add and remove things from your cart
and details like shipping options change.

This would massively simplify the shipping experience and make every web
shop feel like Amazon.

Of course this has privacy implications and increases exposure to potential
wallet exploits, but the wallet can ask you if you intend to shop or not at
each site before it even connects and send any information at all in order
to mitigate both of those problems. This way it should be reasonably safe.

Another option would be to automatically connect but limit what data is
sent in order to remain privacy preserving, until the user agrees to send
private information.

This second method would also open up for the merchant to other send
relevant information such as details about various certifications from
third parties, which can include a certification that shows they have been
been audited and approved by by entity X for purpose Y. If your wallet has
that entity whitelisted it will show you that certificate (for example
Acme Audits have audited and approves of Merchant M's privacy policy and
data protection). With a list of predefined types of certifications that
the wallet understand and accepts, it could (by choice of the user) require
a certificate to be present to even allow you to make a purchase (lack of
required certifications would result in automatic denial). No certificate =
your wallet never proceed to send private information.

Thoughts?

- Sent from my tablet
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

2015-02-10 Thread MⒶrtin HⒶboⓋštiak
Why would anyone want to do anything about payment before choosing
what he wants to buy and for what price? I've never used Amazon but
isn't filling a form with shipping information enough?

2015-02-10 11:21 GMT+01:00 Natanael natanae...@gmail.com:
 BIP70 is a protocol for getting a user's wallet client communicate with a
 merchant's server in order to agree on details like where to send the
 payment, how much to send, what the shipping address is, sending a receipt
 back, and much more using various extensions that adds more functionality.

 There could even be advanced functionality for automatically negotiating
 terms. One example could be selecting a multisignature arbitrator both sides
 trust. Another could be to agree on the speed and type of delivery. Many
 more types of decisions could be automatically agreed upon.

 But as it is now, it is designed to be initiated at the time of payment. If
 you always want next-day delivery from online stores then you won't always
 know if that's an option until you've filled the digital basket and gone
 through checkout. If you only want to shop with an arbitrator involved same
 thing applies.

 Everything that BIP70 enables happens at the last step only, as it is right
 now.

 If there could be a BIP70 HTML tag on web shops that automatically triggered
 your wallet as soon as you visit the page, it would be possible for a
 browser extension that talks to your wallet to tell you right away if the
 web shop you're currently looking at has terms you consider acceptable or
 not (note: if your wallet client isn't installed on or linked to that same
 machine, a visible Qr code would be an acceptable alternative which you can
 scan in advance before you start shopping). This notification can even be
 automatically updated as you add and remove things from your cart and
 details like shipping options change.

 This would massively simplify the shipping experience and make every web
 shop feel like Amazon.

 Of course this has privacy implications and increases exposure to potential
 wallet exploits, but the wallet can ask you if you intend to shop or not at
 each site before it even connects and send any information at all in order
 to mitigate both of those problems. This way it should be reasonably safe.

 Another option would be to automatically connect but limit what data is sent
 in order to remain privacy preserving, until the user agrees to send private
 information.

 This second method would also open up for the merchant to other send
 relevant information such as details about various certifications from third
 parties, which can include a certification that shows they have been been
 audited and approved by by entity X for purpose Y. If your wallet has that
 entity whitelisted it will show you that certificate (for example Acme
 Audits have audited and approves of Merchant M's privacy policy and data
 protection). With a list of predefined types of certifications that the
 wallet understand and accepts, it could (by choice of the user) require a
 certificate to be present to even allow you to make a purchase (lack of
 required certifications would result in automatic denial). No certificate =
 your wallet never proceed to send private information.

 Thoughts?

 - Sent from my tablet


 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

2015-02-10 Thread Natanael
Den 10 feb 2015 11:34 skrev MⒶrtin HⒶboⓋštiak martin.habovst...@gmail.com
:

 Why would anyone want to do anything about payment before choosing
 what he wants to buy and for what price? I've never used Amazon but
 isn't filling a form with shipping information enough?

That's not what this is about.

BIP70 isn't just payment, it is about communication the terms of the sale.

Let's say you're visiting an international webshop. But they don't ship to
your country. Wouldn't you want to know that before your start filling the
cart? With this, your wallet / browser extension could tell you right away
that you can't shop there. No time wasted!

That's just one requirement of many where you would benefit from being told
right away if it is acceptable for both parties or not.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

2015-02-10 Thread Oleg Andreev
 Let's say you're visiting an international webshop. But they don't ship to 
 your country. Wouldn't you want to know that before your start filling the 
 cart? With this, your wallet / browser extension could tell you right away 
 that you can't shop there. No time wasted!

Why my wallet has to do anything with me being in some country? The webshop may 
detect my location and tell me if they ship to where I'm currently in. Why 
should I associate more private information (my location) with my wallet than 
strictly necessary? Why should I automatically advertise my shipping address to 
every webshop without my explicit consent?

The wallet must be convenient only as much as it allows for better security and 
privacy, but not trading off security and privacy for some unrelated 
convenience. --
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

2015-02-10 Thread Eric Voskuil
On 02/10/2015 02:41 AM, Natanael wrote:
 Den 10 feb 2015 11:34 skrev MⒶrtin HⒶboⓋštiak
 martin.habovst...@gmail.com mailto:martin.habovst...@gmail.com:

 Why would anyone want to do anything about payment before choosing
 what he wants to buy and for what price? I've never used Amazon but
 isn't filling a form with shipping information enough?
 
 That's not what this is about.
 
 BIP70 isn't just payment, it is about communication the terms of the sale.

Hi Natanael,

BIP70 exists for seller non-repudiation (i.e. a cryptographically signed
receipt for payment) and establishing strong seller identity in a
face-to-face or other non-web scenario (since TLS doesn't help).
Anything else is incidental.

 Let's say you're visiting an international webshop. But they don't ship
 to your country. Wouldn't you want to know that before your start
 filling the cart? With this, your wallet / browser extension could tell
 you right away that you can't shop there. No time wasted!
 
 That's just one requirement of many where you would benefit from being
 told right away if it is acceptable for both parties or not.

There's quite a bit that can be done with wallets and web sites, but
personally I'd freak out if my wallet prompted me because I visited a
web site.

e



signature.asc
Description: OpenPGP digital signature
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

2015-02-10 Thread MⒶrtin HⒶboⓋštiak
I still don't understand. The website can have this information
available. This is exactly what e-bay does - it displays shipping
information to my country before I do anything. What's the problem?

Also with other stuff, website can do it and browser extension can do
it too without messing with Bitcoin.

2015-02-10 11:41 GMT+01:00 Natanael natanae...@gmail.com:
 Den 10 feb 2015 11:34 skrev MⒶrtin HⒶboⓋštiak
 martin.habovst...@gmail.com:

 Why would anyone want to do anything about payment before choosing
 what he wants to buy and for what price? I've never used Amazon but
 isn't filling a form with shipping information enough?

 That's not what this is about.

 BIP70 isn't just payment, it is about communication the terms of the sale.

 Let's say you're visiting an international webshop. But they don't ship to
 your country. Wouldn't you want to know that before your start filling the
 cart? With this, your wallet / browser extension could tell you right away
 that you can't shop there. No time wasted!

 That's just one requirement of many where you would benefit from being told
 right away if it is acceptable for both parties or not.

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

2015-02-10 Thread Natanael
Den 10 feb 2015 11:48 skrev MⒶrtin HⒶboⓋštiak martin.habovst...@gmail.com
:

 I still don't understand. The website can have this information
 available. This is exactly what e-bay does - it displays shipping
 information to my country before I do anything. What's the problem?

 Also with other stuff, website can do it and browser extension can do
 it too without messing with Bitcoin.

1: IP isn't guaranteed to work correctly both because you might be using a
VPN out Tor.

2: Yes, the site can display all options right away, but are you willing to
read all of them too?

3: Detailed information is not necessary, nor does it have to be
unprompted. It doesn't need to tell you more than which country you are in.
It can even prompt you with a popup that has a slider that shows exactly
how much information and of what kind you're about to share (including
none, if that's your choice).

4: It doesn't need to share raw data. Take a look at anonymous credentials:
http://www.zurich.ibm.com/idemix/
https://eprint.iacr.org/2013/622.pdf

5: It can wait for prompting until you add the first item to the cart.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

2015-02-10 Thread MⒶrtin HⒶboⓋštiak
2015-02-10 12:12 GMT+01:00 Natanael natanae...@gmail.com:
 Den 10 feb 2015 11:48 skrev MⒶrtin HⒶboⓋštiak
 martin.habovst...@gmail.com:

 I still don't understand. The website can have this information
 available. This is exactly what e-bay does - it displays shipping
 information to my country before I do anything. What's the problem?

 Also with other stuff, website can do it and browser extension can do
 it too without messing with Bitcoin.

 1: IP isn't guaranteed to work correctly both because you might be using a
 VPN out Tor.

Still possible using web browser extension.

 2: Yes, the site can display all options right away, but are you willing to
 read all of them too?

Why not? And again, browser extension can do it without bitcoin wallet
- no need to connect unrelated things.

 3: Detailed information is not necessary, nor does it have to be unprompted.
 It doesn't need to tell you more than which country you are in. It can even
 prompt you with a popup that has a slider that shows exactly how much
 information and of what kind you're about to share (including none, if
 that's your choice).

 4: It doesn't need to share raw data. Take a look at anonymous credentials:
 http://www.zurich.ibm.com/idemix/
 https://eprint.iacr.org/2013/622.pdf

 5: It can wait for prompting until you add the first item to the cart.

Everything you described is possible without Bitcoin involved - why
would we mix unrelated things?

P.S.: I believe in Unix philosophy. ;)

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

2015-02-10 Thread MⒶrtin HⒶboⓋštiak
2015-02-10 12:19 GMT+01:00 Natanael natanae...@gmail.com:

 Den 10 feb 2015 12:08 skrev Mike Hearn m...@plan99.net:

 We can certainly imagine many BIP70 extensions, but for things like
 auto-filling shipping addresses, is the wallet the best place to do it? My
 browser already knows how to fill out this data in credit card forms, it
 would make sense to reuse that for Bitcoin.

 It sounds like you want a kind of Star-Trek negotiation agent thing, where
 your computer knows how to seek out the best deal because all the metadata
 is standardised. Such a thing would be an interesting project, but it's
 probably not best done in BIP70 given how it's deployed and used today.
 Rather, I'd suggest looking at the various HTML5 data standards which would
 allow merchants to advertise things like where they ship to in a machine
 readable and crawlable form.

 BIP70 doesn't have to be the place, but not needing to make sure the device
 in question have that information stored already would be an improvement.
 What protocol is used doesn't matter much, I just thought reusing BIP70
 would simplify implementation.

In what universe is that simple? Your solution: browser extension +
wallet + comminucation API + all the wallets need to implement it
Our solution: just browser extension.

If you hate writing browser extensions in Javascript, you can say it
directly. ;)


 HTML5 elements could definitely be supported, through adding a tag in the
 HTML form that says prompt the Bitcoin wallet about the following payment
 details.

Just no.


 As one example, your browser could ask your hardware wallet over BLE for
 this data. This way you barely have to trust the computer you're using at
 all, as everything it does is confirmed on the hardware wallet before
 payment (assuming it has a screen, which it should). Linking your hardware
 wallet over BLE to new devices which you then use for browsing and shopping
 could  be trivial and yet allow secure auto-fill of this kind.

This looks more interesting but is information about your location
really so secret that you need to hold it in HW wallet? Because if so,
you probably don't want to use untrusted machine anyway. (Or just use
Qubes OS.)



 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

2015-02-10 Thread Mike Hearn
We can certainly imagine many BIP70 extensions, but for things like
auto-filling shipping addresses, is the wallet the best place to do it? My
browser already knows how to fill out this data in credit card forms, it
would make sense to reuse that for Bitcoin.

It sounds like you want a kind of Star-Trek negotiation agent thing, where
your computer knows how to seek out the best deal because all the metadata
is standardised. Such a thing would be an interesting project, but it's
probably not best done in BIP70 given how it's deployed and used today.
Rather, I'd suggest looking at the various HTML5 data standards which would
allow merchants to advertise things like where they ship to in a machine
readable and crawlable form.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-02-10 Thread Eric Voskuil
On 02/10/2015 09:16 AM, MⒶrtin HⒶboⓋštiak wrote:
 I'm not sure if I was clear enough. Handshake should be used to
 establish authenticated AND encrypted communication using ECDH (or
 just DH, but I think it's easier to use ECDH, since required functions
 are already used in Bitcoin protocol), like RedPhone does. BTW
 knowledge of verification string is useless to the attacker.

Yes, I think this was clear from your description.

 Yes, the customer must verify it verbally and the merchant shouldn't
 send the transaction before verification. Other possibility is that in
 case of differing verification strings new address is generated, so
 attacker doesn't know the address. But in this case, amount is leaked
 and there is quite high probability it can be found in the Blockchain.

Yes, for each handshake the payment request would need to contain a
different address, mitigating some of the privacy loss.

 Anyway, I don't believe the transaction can be made securely without
 such interaction except with white-listing public keys, so I see no
 reason why interaction should be problematic.

It can be done securely and privately by transfer of a shared secret
through a private channel.

 We don't have such strict regulations but I agree that security is
 important. Currently I think that verbal verification and manual
 confirmation is the best way to achieve high security and reasonable
 user-friendliness.

I think for a broadcast model (e.g. Bluetooth only) that is the only
want to ensure integrity and privacy. A narrow cast can use proximity to
establish trust.

 2015-02-10 17:55 GMT+01:00 Eric Voskuil e...@voskuil.org:
 Martin,

 I like your idea for the commit protocol in that it resolves the
 vandalous address substitution attack. However, I don't see a way to
 prevent privacy loss without adverse impact to the scenario.

 Anyone could perform the handshake and thereby obtain the payment
 request. Therefore to prevent inadvertent disclosure the customer must
 visually confirm the phrase and then verbally tell the merchant to
 proceed by sending the payment request.

 One might argue that it's sufficient to preserve the integrity of the
 transaction while suffering the privacy loss, especially given that a
 hijacked handshake should never result in a completed transaction -
 unless of course the hijacker pays.

 But imagine someone purchasing their meds. HIPAA requires the checkout
 queue to form behind a yellow line. That speaks directly to this question.

 e

 On 02/06/2015 01:07 AM, MⒶrtin HⒶboⓋštiak wrote:
 2015-02-06 2:29 GMT+01:00 Eric Voskuil e...@voskuil.org:
 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.

 I have never been against manual verification. What I'm trying to say
 is let's just make manual verification easier and more secure.
 Comparison of address is simpler for the coder but also simpler to
 attack. It has these problems:
 - Addresses broadcasted in plaintext (privacy issue)
 - Amounts broadcasted in plaintext (privacy issue)
 - Address is long - takes lot of time to verify (user experience issue)
 - Address prefix can be brute-forced, if too short or used to make
 black hole address if longer (vandalism issue)

 Commit protocol can be used for both the encryption and the
 authentication while user experience is not bad and everything is
 still secure.


 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
 

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

2015-02-10 Thread MⒶrtin HⒶboⓋštiak
I'm not sure if I was clear enough. Handshake should be used to
establish authenticated AND encrypted communication using ECDH (or
just DH, but I think it's easier to use ECDH, since required functions
are already used in Bitcoin protocol), like RedPhone does. BTW
knowledge of verification string is useless to the attacker.

Yes, the customer must verify it verbally and the merchant shouldn't
send the transaction before verification. Other possibility is that in
case of differing verification strings new address is generated, so
attacker doesn't know the address. But in this case, amount is leaked
and there is quite high probability it can be found in the Blockchain.
Anyway, I don't believe the transaction can be made securely without
such interaction except with white-listing public keys, so I see no
reason why interaction should be problematic.

We don't have such strict regulations but I agree that security is
important. Currently I think that verbal verification and manual
confirmation is the best way to achieve high security and reasonable
user-friendliness.

2015-02-10 17:55 GMT+01:00 Eric Voskuil e...@voskuil.org:
 Martin,

 I like your idea for the commit protocol in that it resolves the
 vandalous address substitution attack. However, I don't see a way to
 prevent privacy loss without adverse impact to the scenario.

 Anyone could perform the handshake and thereby obtain the payment
 request. Therefore to prevent inadvertent disclosure the customer must
 visually confirm the phrase and then verbally tell the merchant to
 proceed by sending the payment request.

 One might argue that it's sufficient to preserve the integrity of the
 transaction while suffering the privacy loss, especially given that a
 hijacked handshake should never result in a completed transaction -
 unless of course the hijacker pays.

 But imagine someone purchasing their meds. HIPAA requires the checkout
 queue to form behind a yellow line. That speaks directly to this question.

 e

 On 02/06/2015 01:07 AM, MⒶrtin HⒶboⓋštiak wrote:
 2015-02-06 2:29 GMT+01:00 Eric Voskuil e...@voskuil.org:
 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.

 I have never been against manual verification. What I'm trying to say
 is let's just make manual verification easier and more secure.
 Comparison of address is simpler for the coder but also simpler to
 attack. It has these problems:
 - Addresses broadcasted in plaintext (privacy issue)
 - Amounts broadcasted in plaintext (privacy issue)
 - Address is long - takes lot of time to verify (user experience issue)
 - Address prefix can be brute-forced, if too short or used to make
 black hole address if longer (vandalism issue)

 Commit protocol can be used for both the encryption and the
 authentication while user experience is not bad and everything is
 still secure.


 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
 e...@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