[Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)
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)
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 : > 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)
Den 10 feb 2015 11:34 skrev "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? 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)
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 : > Den 10 feb 2015 11:34 skrev "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? > > 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)
> 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)
On 02/10/2015 02:41 AM, Natanael wrote: > Den 10 feb 2015 11:34 skrev "MⒶrtin HⒶboⓋštiak" > 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)
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] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)
Den 10 feb 2015 11:48 skrev "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. 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)
Den 10 feb 2015 12:08 skrev "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. 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. 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". 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. -- 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 12:12 GMT+01:00 Natanael : > Den 10 feb 2015 11:48 skrev "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. > > 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 12:19 GMT+01:00 Natanael : > > Den 10 feb 2015 12:08 skrev "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. > > 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)
> 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. Browser extension would only be required until browsers add native support for detecting the tag and prompting a wallet client. This probably won't happen in the near future, though. Also, the kind of browser extension you're talking about would be limited to just one device or require manually configured syncing between your devices, and would also likely be limited to just a few platforms. The communication is done between the wallet and merchant the same as always with BIP70, but with some extra BIP70 extensions for this purpose. It just starts talking earlier. It supports graceful degradation just fine, if the browser or wallet don't support it or the wallet isn't linked to that computer's browser, then nothing out of the ordinary happens. The browser extension really don't do anything special, it just relays the details in the HTML tag. > > 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.) It isn't necessarily top secret, but why not be protective by default? Your hardware wallet is already designed to keep secrets. Lets say you're at a library computer, or at a friend's house, why not let your hardware wallet deal with all the security? In this scenario it is likely already functioning as a central point for all your Bitcoin related purchases anyway, so it might as well be the device that remembers all your shopping preferences for you. So let's make it simple to use! -- 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
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 : >> 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 >> 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
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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 : > 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 : >>> 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 >>> napísal: >>> > On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak wrote: >> That's exactly what I though when s
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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 : >> 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 : 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-
