MⒶrtin HⒶboⓋštiak [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-02-05 to 2015-02-10
💬 Posted a total of 9 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:30:02

- reply

📅 Original date posted:2015-02-10
📝 Original message:2015-02-10 12:19 GMT+01:00 Natanael <natanael.l at gmail.com>:
>
> Den 10 feb 2015 12:08 skrev "Mike Hearn" <mike at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:30:01

- reply

📅 Original date posted:2015-02-10
📝 Original message:2015-02-10 12:12 GMT+01:00 Natanael <natanael.l at gmail.com>:
> Den 10 feb 2015 11:48 skrev "MⒶrtin HⒶboⓋštiak"
> <martin.habovstiak at 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. ;)

2023-06-07 15:30:00

- reply

📅 Original date posted:2015-02-10
📝 Original message: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 <natanael.l at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:30:00

- reply

📅 Original date posted:2015-02-10
📝 Original message: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 <natanael.l at gmail.com>:
> Den 10 feb 2015 11:34 skrev "MⒶrtin HⒶboⓋštiak"
> <martin.habovstiak at 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.

2023-06-07 15:29:49

- reply

📅 Original date posted:2015-02-10
📝 Original message: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 <eric at 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 <eric at 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
>>> <eric at 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 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 <eric at voskuil.org>:
>>>>>>> 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
>>>>>>>
>>>>
>>>>
>>>
>

2023-06-07 15:29:48

- reply

📅 Original date posted:2015-02-06
📝 Original message:2015-02-06 2:29 GMT+01:00 Eric Voskuil <eric at 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
> <eric at 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 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 <eric at voskuil.org>:
>>>>> 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
>>>>>
>>
>>
>

2023-06-07 15:29:46

- reply

📅 Original date posted:2015-02-05
📝 Original message:> 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)?

2023-06-07 15:29:46

- reply

📅 Original date posted:2015-02-05
📝 Original message: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. :)
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.
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.
2015-02-06 0:46 GMT+01:00 Eric Voskuil <eric at voskuil.org>:
> 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
>

2023-06-07 15:29:43

- reply

📅 Original date posted:2015-02-05
📝 Original message:I would like to shortly express my opinion:
- Having BT as an alternative is good idea but it must be secure enough
- Signed BIP70 should be enough. I see only two issues regarding BIP70
(but they apply also to TCP/IP, not just BT): key revocations and MITM
attacks by governments.
- Broadcasting faces is very bad idea IMHO.
- Comparing addresses seems complicated but if hash was displayed as a
unique, picture hard to be mistake or long phrase, it could be more
convenient.
- Maybe storing public key (I do NOT mean bitcoin address!) of
merchant after successful transaction is good compromise?
Another idea: I noticed it's extremely easy to compare two strings if
they are the same size (in terms of millimeters, not number of
characters). If the hash of signing key was printed on a sign near the
POS in specified size (90% of smallest available screen?) and phone
would scale correctly, just putting the phone near the sign would be
enough to instantly spot whether the hashes are same.
Maybe instead of hex/base58 hash encoding use colored barcode. But I'm
not sure if it would improve things.
2015-02-05 23:49 GMT+01:00 Roy Badami <roy at gnomon.org.uk>:
> Personally I like the simplicity of tapping two phones together to
> make payment - it should be quicker and easier than scanning QR codes
> and it's a trust model that's hard to misunderstand.
>
> Is NFC good enough for that? I fear even with NFC it is possible to
> produce a device with longer range than one would expect. What
> happened to the idea of tapping two devices together and then
> comparing the timing of the tap (as detected by the phones'
> accelerometers) to make spoofing a transaction harder? I remember
> hearing about that years ago - is that still a thing?
>
> roy
>
> On Thu, Feb 05, 2015 at 02:10:51PM -0800, Eric Voskuil wrote:
>> A MITM can receive the initial broadcast and then spoof it by jamming the original. You then only see one.
>>
>> e
>>
>> > On Feb 5, 2015, at 2:07 PM, Paul Puey <paul at airbitz.co> wrote:
>> >
>> > So if you picked up the BLE broadcast request. All you know is that *someone* within 100m is requesting bitcoin at a certain address. Not necessarily who. The *name* is both optional, and possibly just a *handle* of the user. If I'm sitting 5 ft away from someone at dinner and wanted to pay them via BLE, I might see "Monkey Dude" on my list and simply ask him "is that you?" If so, I send it. If there are two "Monkey Dude's" Then I have to bother with the address prefix, but not otherwise.
>> >
>> >> On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil <eric at voskuil.org> wrote:
>> >> BLE has an advertised range of over 100m.
>> >>
>> >> http://www.bluetooth.com/Pages/low-energy-tech-info.aspx
>> >>
>> >> In the case of mass surveillance that range could most likely be extended dramatically by the reviewer. I've seen WiFi ranges of over a mile with a strong (not FCC approved) receiver.
>> >>
>> >> WiFi hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location.
>> >>
>> >> e
>> >>
>> >> On Feb 5, 2015, at 1:36 PM, Mike Hearn <mike at plan99.net> wrote:
>> >>
>> >>>> This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition.
>> >>>
>> >>> We're talking about BLE, still? The radio tech that runs in the so called "junk bands" because propagation is so poor?
>> >>>
>> >>> My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls.
>> >>>
>> >>> Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup.
>> >>>
>> >>> Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it.
>> >
>
>> ------------------------------------------------------------------------------
>> 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development