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 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 : >>>> 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 >>>> > >