Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-05 Thread Martin Habovštiak
-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 e...@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 e...@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


- --
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==
=J4w/
-END PGP SIGNATURE-


--
Dive into the World of Parallel Programming. The Go Parallel Website,

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-05 Thread Martin Habovštiak
-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 p...@airbitz.co 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 e...@voskuil.org 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 to address Bitcoin malware

2015-02-02 Thread Martin Habovštiak
Do you have anything that is NOT some web application?

2015-02-02 18:59 GMT+01:00 Mike Hearn m...@plan99.net:
 We're way ahead of you guys ;)

 On Mon, Feb 2, 2015 at 6:54 PM, Martin Habovštiak
 martin.habovst...@gmail.com 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

2015-02-02 Thread Martin Habovštiak
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 brian.erde...@gmail.com:
 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


[Bitcoin-development] New BIP: protocol for multisignature payments

2015-01-30 Thread Martin Habovštiak
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


Re: [Bitcoin-development] New BIP: protocol for multisignature payments

2015-01-31 Thread Martin Habovštiak
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 m...@plan99.net:
 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
 martin.habovst...@gmail.com 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


Re: [Bitcoin-development] New BIP: protocol for multisignature payments

2015-01-31 Thread Martin Habovštiak
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 gavinandre...@gmail.com:
 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 m...@plan99.net 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

2015-02-01 Thread Martin Habovštiak
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 brian.erde...@gmail.com:

 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