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