Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Commit protocol provides both better user experience and better security. Dňa 6. februára 2015 1:49:12 CET používateľ Paul Puey napísal: >The trust can be considered bootstrapped by visual verification of the >address prefix. If we are really concerned about someone jamming a >Bluetooth signal in a coffeeshop then the UI can encourage verification >of the prefix. Much like how regular Bluetooth requires 'pairing' via >entering a 4-6 digit code. > > > >Paul Puey CEO / Co-Founder, Airbitz Inc >619.850.8624 | http://airbitz.co | San Diego > > > > >On Feb 5, 2015, at 3:46 PM, Eric Voskuil wrote: > >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 - -- Odoslané z môjho Android zariadenia pomocou K-9 Mail. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iI8EAREKADcFAlTUD/AwHE1hcnRpbiBIYWJvdmF0aWFrIDxtYXJ0aW4uaGFib3Zz dGlha0BnbWFpbC5jb20+AAoJED6C3NvqapyUPwgA/0eVlJYeA3fYmVb1zVA8j1l/ kjOhc9CIDYL9ifk8N0t/AP4mC4CwmZoNXqr24le5WdYeBeyHMiDMtJrRfwQkN1LG dQ== =pY76 -END PGP 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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. :) 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. 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.) 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 >>> - -- Odoslané z môjho Android zariadenia pomocou K-9 Mail. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iI8EAREKADcFAlTUDKEwHE1hcnRpbiBIYWJvdmF0aWFrIDxtYXJ0aW4uaGFib3Zz dGlha0BnbWFpbC5jb20+AAoJED6C3NvqapyUfUgA/2j6jQELBtSrNsle7ybGq1D8 uWgGwevguCnjPd0pEpWgAP42sS/ekCqs1v9wbART9fLprZTBk4YPllwXifss+9sa zQ==
Re: [Bitcoin-development] Proposal to address Bitcoin malware
Do you have anything that is NOT some web application? 2015-02-02 18:59 GMT+01:00 Mike Hearn : > We're way ahead of you guys ;) > > On Mon, Feb 2, 2015 at 6:54 PM, Martin Habovštiak > wrote: >> >> Good idea. I think this could be even better: >> >> instead of using third party, send partially signed TX from computer >> to smartphone. In case, you are paranoid, make 3oo5 address made of >> two cold storage keys, one on desktop/laptop, one on smartphone, one >> using third party. > > > https://www.bitcoinauthenticator.org/ - does this already, currently in > alpha > >> >> > It should be possible to use multisig wallets to protect against >> > malware. For example, a user could generate a wallet with 3 keys and >> > require a transaction that has been signed by 2 of those keys. One key is >> > placed in cold storage and anther sent to a third-party. > > > BitGo, CryptoCorp and (slight variant) GreenAddress all offer this model. -- 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 to address Bitcoin malware
Good idea. I think this could be even better: instead of using third party, send partially signed TX from computer to smartphone. In case, you are paranoid, make 3oo5 address made of two cold storage keys, one on desktop/laptop, one on smartphone, one using third party. If it isn't enough, add requirement of another four keys, so you have three desktops with different OS (Linux, Windows, Mac) and three mobile OS (Android, iOS, Windows Phone), third party and some keys in cold storage. Also, I forgot HW wallets, so at least Trezor and Ledger. I believe this scheme is unpenetrable by anyone, including NSA, FBI, CIA, NBU... Jokes aside, I think leaving out third party is important for privacy reasons. Stay safe! 2015-02-02 18:40 GMT+01:00 Brian Erdelyi : > Another concept... > > It should be possible to use multisig wallets to protect against malware. > For example, a user could generate a wallet with 3 keys and require a > transaction that has been signed by 2 of those keys. One key is placed in > cold storage and anther sent to a third-party. > > It is now possible to generate and sign transactions on the users computer > and send this signed transaction to the third-party for the second signature. > This now permits the use of out of band transaction verification techniques > before the third party signs the transaction and sends to the blockchain. > > If the third-party is malicious or becomes compromised they would not have > the ability to complete transactions as they only have one private key. If > the third-party disappeared, the user could use the key in cold storage to > sign transactions and send funds to a new wallet. > > Thoughts? > -- > 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] New BIP: protocol for multisignature payments
Both wallet and server side implementations will be based on existing
code in me-friendly language (C++>Python>anything else). I don't have
a time for it right now but Crypto hackathon in Parallel Polis
(http://cryptohack.org/) seems like good opportunity for it. I will
let you know then.
2015-02-01 14:43 GMT+01:00 Mike Hearn :
> If you decide to implement this in an existing or new bitcoinj based wallet,
> then I'm happy to give you pointers on how to do it. Making one-off, cross
> platform app specific wallets is pretty easy these days. For 2-of-3 dispute
> mediation transactions they'd start out being kind of specialist so asking
> people to move money from their general spending wallet into dispute
> mediation app isn't unthinkable. Eventually general purpose wallets would
> integrate protocol, UI ideas and maybe code.
>
> At least, that's how I'd do it.
>
> On Sun, Feb 1, 2015 at 12:02 AM, Martin Habovštiak
> wrote:
>>
>> I didn't consider that, thank you for feedback! I will try to find
>> some time for implementing it. I'll write again then.
>>
>> 2015-01-31 23:50 GMT+02:00 Gavin Andresen :
>> > I agree- standards should be descriptive ("here is how this thing I did
>> > works") and NOT proscriptive ("here's what I think will work, lets all
>> > try
>> > to do it this way.").
>> >
>> >
>> > On Sat, Jan 31, 2015 at 2:07 PM, Mike Hearn wrote:
>> >>>
>> >>> I could look at implementing it someday, but now I'd like to receive
>> >>> feedback from community.
>> >>
>> >>
>> >> IMO it's better to pair a protocol spec with an implementation.
>> >
>> >
>> > --
>> > --
>> > Gavin Andresen
>
>
--
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 to address Bitcoin malware
BIP70 is quite safe agains MitB. If user copies URL belonging to other merchant, he would see the fact after entering it into his wallet application. The only problem is, attacker can buy from the same merchant with user's money. (sending him different URL) This can be mitigated by merchant setting "memo" to the description of the basket and some user info (e.g. address to which goods are sent). But if whole computer is compromised, you're already screwed. Trezor should help, but I'm not sure if it supports BIP70. 2015-02-01 14:49 GMT+02:00 Brian Erdelyi : > > In online banking, the banks generate account numbers. An attacker cannot > generate their own account number and the likelihood of an attacker having > the same account number that I am trying to transfer funds to is low and > this is why OCRA is effective with online banking. > > With Bitcoin, the Bitcoin address is comparable to the recipient’s bank > account number. I now see how an an attacker can brute force the bitcoin > address with vanitygen. Is there any way to generate an 8 digit number from > the bitcoin address that can be used to verify transactions in such a way > (possibly with hashing?) that brute forcing a bitcoin address would take > longer than a reasonable period of time (say 60 seconds) so a system could > time out if a transaction was not completed in that time? > > I’ve also looked into BIP70 (Payment Protocol) that claims protection > against man-in-the-middle/man-in-the-browser (MitB) based attacks. A common > way to protect against this is with out-of-band transaction verification > (http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_verification). > I see how BIP 70 verifies the payment request, however, is there any way to > verify that the transaction signed by the wallet matches the request before > it is sent to the blockchain (and how can this support out of band > verification)? Perhaps this is something that can only be supported when > sending money with web based wallets. > > Brian Erdelyi > > -- > 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] New BIP: protocol for multisignature payments
I didn't consider that, thank you for feedback! I will try to find
some time for implementing it. I'll write again then.
2015-01-31 23:50 GMT+02:00 Gavin Andresen :
> I agree- standards should be descriptive ("here is how this thing I did
> works") and NOT proscriptive ("here's what I think will work, lets all try
> to do it this way.").
>
>
> On Sat, Jan 31, 2015 at 2:07 PM, Mike Hearn wrote:
>>>
>>> I could look at implementing it someday, but now I'd like to receive
>>> feedback from community.
>>
>>
>> IMO it's better to pair a protocol spec with an implementation.
>
>
> --
> --
> Gavin Andresen
--
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] New BIP: protocol for multisignature payments
I know about that wiki page. I just wanted to design protocol which would make it easier in practice. (now it would be done manually) I could look at implementing it someday, but now I'd like to receive feedback from community. 2015-01-31 19:19 GMT+02:00 Mike Hearn : > Hi Martin, > > You're on the right lines. Your writeup is pretty similar to the high level > overview given here though: > > https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation > > To make 2-of-3 dispute mediation works requires implementing a wallet that > supports it, and the tools mediators need to manage incoming tickets, etc. > The BIP70 extension is probably the smallest part of the project. > > > On Sat, Jan 31, 2015 at 2:30 AM, Martin Habovštiak > wrote: >> >> Hello, >> >> I've been thinking about how to solve security problems of the servers >> holding huge amounts of bitcoins (exchanges, markets...) and came up >> with this idea: https://gist.github.com/Kixunil/2ec79cf40a53fb899ac5 >> >> TL;DR: it's extension of BIP70 (but not fully compatible due to security >> reasons) which supports making of multisig transactions dynamically. >> (The most important thing is that the user provides his address.) >> >> What do you think? Is it a good way to solve the problem or do you know >> about something better? I would really like this or something similar >> implemented by wallets. >> >> Thank you for your feedback! >> >> Martin >> >> >> -- >> 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
[Bitcoin-development] New BIP: protocol for multisignature payments
Hello, I've been thinking about how to solve security problems of the servers holding huge amounts of bitcoins (exchanges, markets...) and came up with this idea: https://gist.github.com/Kixunil/2ec79cf40a53fb899ac5 TL;DR: it's extension of BIP70 (but not fully compatible due to security reasons) which supports making of multisig transactions dynamically. (The most important thing is that the user provides his address.) What do you think? Is it a good way to solve the problem or do you know about something better? I would really like this or something similar implemented by wallets. Thank you for your feedback! Martin signature.asc Description: This is a digitally signed message part -- 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
