Re: [Bitcoin-development] Proposal to address Bitcoin malware
Confusing or not, the reliance on multiple signatures as offering greater security than single relies on the independence of multiple secrets. If the secrets cannot be shown to retain independence in the envisioned threat scenario (e.g. a user's compromised operating system) then the benefit reduces to making the exploit more difficult to write, which, once written, reduces to no benefit. Yet the user still suffers the reduced utility arising from greater complexity, while being led to believe in a false promise. Just trying to make sure I understand what you’re saying. Are you eluding to that if two of the three private keys get compromised there is no gain in security? Although the likelihood of this occurring is lower, it is possible. As more malware targets bitcoins I think the utility is evident. Given how final Bitcoin transactions are, I think it’s worth trying to find methods to help verify those transactions (if a user deems it to be high-risk enough) before the transaction is completed. The balance is trying to devise something that users do not find too burdensome. 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
Re: [Bitcoin-development] Proposal to address Bitcoin malware
There are a couple of attack vectors to consider: * The recipient's machine is compromised * The sender's machine is compromised Excellent point of the recipient being compromised. -- 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
Joel, The mobile device should show you the details of the transaction (i.e. amount and bitcoin address). Once you verify this is the intended recipient and amount you approve it on the mobile device. If the address was replaced, you should see this on the mobile device as it won’t match where you were intending to send it. You can then not provide the second signature. Brian Erdelyi On Feb 2, 2015, at 4:57 PM, Joel Joonatan Kaartinen joel.kaarti...@gmail.com wrote: If the attacker has your desktop computer but not the mobile that's acting as an independent second factor, how are you then supposed to be able to tell you're not signing the correct transaction on the mobile? If the address was replaced with the attacker's address, it'll look like everything is ok. - Joel On Mon, Feb 2, 2015 at 9:58 PM, Brian Erdelyi brian.erde...@gmail.com mailto:brian.erde...@gmail.com wrote: Confusing or not, the reliance on multiple signatures as offering greater security than single relies on the independence of multiple secrets. If the secrets cannot be shown to retain independence in the envisioned threat scenario (e.g. a user's compromised operating system) then the benefit reduces to making the exploit more difficult to write, which, once written, reduces to no benefit. Yet the user still suffers the reduced utility arising from greater complexity, while being led to believe in a false promise. Just trying to make sure I understand what you’re saying. Are you eluding to that if two of the three private keys get compromised there is no gain in security? Although the likelihood of this occurring is lower, it is possible. As more malware targets bitcoins I think the utility is evident. Given how final Bitcoin transactions are, I think it’s worth trying to find methods to help verify those transactions (if a user deems it to be high-risk enough) before the transaction is completed. The balance is trying to devise something that users do not find too burdensome. 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/ http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development 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] Proposal to address Bitcoin malware
Transaction initiated and signed on device #1. Transaction is sent to device #2. On device #2 you verify the transaction and if authorized you provide the second signature. Brian Erdelyi Sent from my iPhone On Feb 2, 2015, at 5:09 PM, Pedro Worcel pe...@worcel.com wrote: Where would you verify that? On 2/3/2015 10:03 AM, Brian Erdelyi wrote: Joel, The mobile device should show you the details of the transaction (i.e. amount and bitcoin address). Once you verify this is the intended recipient and amount you approve it on the mobile device. If the address was replaced, you should see this on the mobile device as it won’t match where you were intending to send it. You can then not provide the second signature. Brian Erdelyi On Feb 2, 2015, at 4:57 PM, Joel Joonatan Kaartinen joel.kaarti...@gmail.com wrote: If the attacker has your desktop computer but not the mobile that's acting as an independent second factor, how are you then supposed to be able to tell you're not signing the correct transaction on the mobile? If the address was replaced with the attacker's address, it'll look like everything is ok. - Joel On Mon, Feb 2, 2015 at 9:58 PM, Brian Erdelyi brian.erde...@gmail.com wrote: Confusing or not, the reliance on multiple signatures as offering greater security than single relies on the independence of multiple secrets. If the secrets cannot be shown to retain independence in the envisioned threat scenario (e.g. a user's compromised operating system) then the benefit reduces to making the exploit more difficult to write, which, once written, reduces to no benefit. Yet the user still suffers the reduced utility arising from greater complexity, while being led to believe in a false promise. Just trying to make sure I understand what you’re saying. Are you eluding to that if two of the three private keys get compromised there is no gain in security? Although the likelihood of this occurring is lower, it is possible. As more malware targets bitcoins I think the utility is evident. Given how final Bitcoin transactions are, I think it’s worth trying to find methods to help verify those transactions (if a user deems it to be high-risk enough) before the transaction is completed. The balance is trying to devise something that users do not find too burdensome. 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 -- 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 smime.p7s Description: S/MIME cryptographic 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
Re: [Bitcoin-development] Proposal to address Bitcoin malware
If the attacker has your desktop computer but not the mobile that's acting as an independent second factor, how are you then supposed to be able to tell you're not signing the correct transaction on the mobile? If the address was replaced with the attacker's address, it'll look like everything is ok. - Joel On Mon, Feb 2, 2015 at 9:58 PM, Brian Erdelyi brian.erde...@gmail.com wrote: Confusing or not, the reliance on multiple signatures as offering greater security than single relies on the independence of multiple secrets. If the secrets cannot be shown to retain independence in the envisioned threat scenario (e.g. a user's compromised operating system) then the benefit reduces to making the exploit more difficult to write, which, once written, reduces to no benefit. Yet the user still suffers the reduced utility arising from greater complexity, while being led to believe in a false promise. Just trying to make sure I understand what you’re saying. Are you eluding to that if two of the three private keys get compromised there is no gain in security? Although the likelihood of this occurring is lower, it is possible. As more malware targets bitcoins I think the utility is evident. Given how final Bitcoin transactions are, I think it’s worth trying to find methods to help verify those transactions (if a user deems it to be high-risk enough) before the transaction is completed. The balance is trying to devise something that users do not find too burdensome. 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] [softfork proposal] Strict DER signatures
On Sun, Jan 25, 2015 at 6:48 AM, Gregory Maxwell gmaxw...@gmail.com wrote: So I think we should just go ahead with R/S length upper bounds as both IsStandard and in STRICTDER. I would like to fix this at some point in any case. If we want to do that, we must at least have signatures with too-long R or S values as non-standard. One way to do that is to just - right now - add a patch to 0.10 to make those non-standard. This requires another validation flag, with a bunch of switching logic. The much simpler alternative is just adding this to BIP66's DERSIG right now, which is a one-line change that's obviously softforking. Is anyone opposed to doing so at this stage? -- Pieter -- 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
On Feb 2, 2015, at 11:53 AM, Mike Hearn m...@plan99.net wrote: In sending the first-signed transaction to another for second signature, how does the first signer authenticate to the second without compromising the independence of the two factors? Not sure what you mean. The idea is the second factor displays the transaction and the user confirms it matches what they input to the first factor. Ideally, using BIP70, but I don't know if BA actually uses that currently. It's the same model as the TREZOR, except with a desktop app instead of myTREZOR and a phone instead of a dedicated hardware device. Sorry for the slow reply, traveling. My comments were made in reference to this proposal: On Feb 2, 2015, at 10:40 AM, Brian Erdelyi brian.erde...@gmail.com wrote: 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? In the multisig scenario the presumption is of a user platform compromised by malware. It envisions a user signing a 2 of 3 output with a first signature. The precondition that the platform is compromised implies that this process results in a loss of integrity of the private key, and as such if it were not for the second signature requirement, the malware would be able to spend the output. This may be extended to all of the keys in the wallet. The scenario envisions sending the signed transaction to an another (third) party. The objective is for the third party to provide the second signature, thereby spending the output as intended by the user, who is not necessarily the first signer. The send must be authenticated to the user. Otherwise the third party would have to sign anything it received, obviously rendering the second signature pointless. This implies that the compromised platform must transmit a secret, or proof of a secret, to the third party. The problem is that the two secrets are not independent if the first platform is compromised. So of course the malware has the ability to sign, impersonate the user and send to the third party. So the third party *must* send the transaction to an *independent* platform for verification by the user, and obtain consent before adding the second signature. The user, upon receiving the transaction details, must be able to verify, on the independent platform, that the details match those of the transaction that user presumably signed. Even for simple transactions this must include amount, address and fees. The central assumptions are that, while the second user platform may be compromised, the attack against the second platform is not coordinated with that of the first, nor is the third party in collusion with the first platform. Upon these assumptions rests the actual security benefit (increased difficulty of the coordinated attack). The strength of these assumptions is an interesting question, since it is hard to quantify. But without independence the entire security model is destroyed and there is thus no protection whatsoever against malware. So for example a web-based or other third-party-provisioned implementation of the first platform breaks the anti-collusion assumption. Also, weak comsec allows an attack against the second platform to be carried out against its network. So for example a simple SMS-based confirmation could be executed by the first platform alone and thereby also break the the anti-collusion assumption. This is why I asked how independence is maintained. The assumption of a hardware wallet scenario is that the device itself is not compromised. So the scenario is not the same. If the user signs with a hardware wallet, nothing can collude with that process, with one caveat. While a hardware wallet is not subject to onboard malware, it is not inconceivable that its keys could be extracted through probing or other direct attack against the hardware. It's nevertheless an assumption of hardware wallets that these attacks require loss of the hardware. Physical possession constitutes compromise. So the collusion model with a hardware wallet does exist, it just requires device possession. Depending on the implementation the extraction
Re: [Bitcoin-development] Export format for xpub
On 03/02/15 01:05, Andreas Schildbach wrote: I don't think that parameterizing will work, we can't predict future BIPs. It's the same as for BIP43, in the end we agreed on just putting the BIP number. Hm, let me put the questions the other way around: What gap limit should a wallet use if it encounters h=bip32? What h value should I use for myTREZOR wallets? Which is essentially a BIP44 wallet that produces h=bip32 xpubs with gap limit 20 ... -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- 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] Export format for xpub
On 02/02/2015 03:47 PM, vv01f wrote: Uff, I would expect MMDD there so it's human readable as well. Those strings are not meant to be read by humans. MMDD is more complicated than necessary, given that Bitcoin deals with seconds since epoch everywhere. First that is a pitty .. as its simply a waste of storage. but back to Pavol's point: IMHO no harm to anything, as Bitcoin never has any valid timestamp below ~1230768000 (jan2009) and thus will always have 10 digits.. you can easily identify 8 char long timestamp as the proposed format. And there never is anything wrong with having a transparent, human readable option - especially when it saves 2 bytes in e.g. qr-codes. Pavol's suggestion saves 2 chars only because its just a date. I think the creation date should be at least precise to the hour, if not to the minute. But anyhow, if everyone prefers a human readble date format I will bow to the majority. -- 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] Export format for xpub
On 02/02/2015 03:56 PM, Pavol Rusnak wrote: To me it seems more important to describe how addresses should be discovered (i.e. to scan xpub/0/i and xpub/1/j chains using gap limit G) instead of how the xpub was created/obtained (bip32 vs bip44). What do you thing about changing ?h=bip32 to something like ?t=01g=20 - t=01 meaning that chains 0 and 1 should be scanned (feel free to change 01 into any other descriptive string) - g=20 meaning that gap 20 should be used I don't think that parameterizing will work, we can't predict future BIPs. It's the same as for BIP43, in the end we agreed on just putting the BIP number. -- 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
One clarification below. e On 02/02/2015 02:54 PM, Eric Voskuil wrote: On Feb 2, 2015, at 11:53 AM, Mike Hearn wrote: In sending the first-signed transaction to another for second signature, how does the first signer authenticate to the second without compromising the independence of the two factors? Not sure what you mean. The idea is the second factor displays the transaction and the user confirms it matches what they input to the first factor. Ideally, using BIP70, but I don't know if BA actually uses that currently. It's the same model as the TREZOR, except with a desktop app instead of myTREZOR and a phone instead of a dedicated hardware device. Sorry for the slow reply, traveling. My comments were made in reference to this proposal: On Feb 2, 2015, at 10:40 AM, Brian Erdelyi brian.erde...@gmail.com mailto:brian.erde...@gmail.com wrote: 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? My comments below start out with the presumption of user platform compromise, but the same analysis holds for the case where the user platform is clean but a web wallet is compromised. Obviously the idea is that either or both may be compromised, but integrity is retained as long as both are not compromised and in collusion. In the multisig scenario the presumption is of a user platform compromised by malware. It envisions a user signing a 2 of 3 output with a first signature. The precondition that the platform is compromised implies that this process results in a loss of integrity of the private key, and as such if it were not for the second signature requirement, the malware would be able to spend the output. This may be extended to all of the keys in the wallet. The scenario envisions sending the signed transaction to an another (third) party. The objective is for the third party to provide the second signature, thereby spending the output as intended by the user, who is not necessarily the first signer. The send must be authenticated to the user. Otherwise the third party would have to sign anything it received, obviously rendering the second signature pointless. This implies that the compromised platform must transmit a secret, or proof of a secret, to the third party. The problem is that the two secrets are not independent if the first platform is compromised. So of course the malware has the ability to sign, impersonate the user and send to the third party. So the third party *must* send the transaction to an *independent* platform for verification by the user, and obtain consent before adding the second signature. The user, upon receiving the transaction details, must be able to verify, on the independent platform, that the details match those of the transaction that user presumably signed. Even for simple transactions this must include amount, address and fees. The central assumptions are that, while the second user platform may be compromised, the attack against the second platform is not coordinated with that of the first, nor is the third party in collusion with the first platform. Upon these assumptions rests the actual security benefit (increased difficulty of the coordinated attack). The strength of these assumptions is an interesting question, since it is hard to quantify. But without independence the entire security model is destroyed and there is thus no protection whatsoever against malware. So for example a web-based or other third-party-provisioned implementation of the first platform breaks the anti-collusion assumption. Also, weak comsec allows an attack against the second platform to be carried out against its network. So for example a simple SMS-based confirmation could be executed by the first platform alone and thereby also break the the anti-collusion assumption. This is why I asked how independence is maintained. The assumption of a hardware wallet scenario is that the device itself is not compromised. So the scenario is not the same. If the user signs with a hardware wallet, nothing can collude with that process, with one caveat. While a hardware wallet is not subject to
Re: [Bitcoin-development] Export format for xpub
On 02/02/2015 12:33 PM, Mike Hearn wrote: I looked at what Andreas is doing a few days ago - basically it's just an xpub string with a ?a=bc=d query string added to the end, with a hierarchy type specifier and something else I forgot, encoded into a QR code. It's h=bip32 for the hierarchy used and c=123456 for the creation date of the wallet (in seconds since epoch). I pondered about if we should add a scheme (e.g. bitcoin-xpub:) but decided to start without. The only advantage I currently see would be it could be used on Android to dispatch intents to the right app(s). -- 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] Export format for xpub
On 02/02/15 12:33, Mike Hearn wrote: We generally don't edit BIPs like that after they've been written except to I think this could end up in BIP43, which deals with hierarchies and is still in Draft state although widely used. Allocating new BIP seems like a overkill to me. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- 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] Export format for xpub
On 02/02/2015 01:59 PM, Pavol Rusnak wrote: It's h=bip32 for the hierarchy used and Do I understand this correctly and h=bip32 hierarchy means that both xpub/0/i and xpub/1/j chains are scanned? (So it applies to BIP44 generated xpubs as well?) Yes, except that BIP32-hierarchy and BIP44 differ in some requirements (e.g. gap limit). c=123456 for the creation date of the wallet (in seconds since epoch). Uff, I would expect MMDD there so it's human readable as well. Those strings are not meant to be read by humans. MMDD is more complicated than necessary, given that Bitcoin deals with seconds since epoch everywhere. -- 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] Export format for xpub
On Mon, 2 Feb 2015, Levin Keller wrote: Hello everyone, I think this is my first email to this mailinglist so I will shortly introduce myself: I am Levin and the CEO of Coyno (www.coyno.com). Based in Berlin, mathematician. Bitcoiner since 2011. And now the reason for this email: Andreas (Schildbach) just released a new update of his wallet. It now provides an export functionality for the m/0' key in order to run read only copies on other devices. We already support the format on our website. Of course we would love for this to become standard. I also updated the Wiki article for Andreas' Wallet: https://en.bitcoin.it/wiki/Bitcoin_Wallet Yes, standardizing on a format could be useful. How do you like it? How does this format get standard? Shall I try to get a pull request to BIP32 passed? Just administrative trivia: this would be a new BIP, and not an amandment to BIP32. Excluding small language errors and clarifications in examples, BIPs are not changed after the fact. Wladimir-- 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] [softfork proposal] Strict DER signatures
On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille pieter.wui...@gmail.com wrote: The much simpler alternative is just adding this to BIP66's DERSIG right now, which is a one-line change that's obviously softforking. Is anyone opposed to doing so at this stage? Thats my preference. -- 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] Export format for xpub
On 02/02/15 15:17, Andreas Schildbach wrote: Yes, except that BIP32-hierarchy and BIP44 differ in some requirements (e.g. gap limit). Right. To me it seems more important to describe how addresses should be discovered (i.e. to scan xpub/0/i and xpub/1/j chains using gap limit G) instead of how the xpub was created/obtained (bip32 vs bip44). What do you thing about changing ?h=bip32 to something like ?t=01g=20 - t=01 meaning that chains 0 and 1 should be scanned (feel free to change 01 into any other descriptive string) - g=20 meaning that gap 20 should be used Those strings are not meant to be read by humans. MMDD is more complicated than necessary, given that Bitcoin deals with seconds since epoch everywhere. OK :-) -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- 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
On 02/02/2015 11:58 AM, Brian Erdelyi wrote: Confusing or not, the reliance on multiple signatures as offering greater security than single relies on the independence of multiple secrets. If the secrets cannot be shown to retain independence in the envisioned threat scenario (e.g. a user's compromised operating system) then the benefit reduces to making the exploit more difficult to write, which, once written, reduces to no benefit. Yet the user still suffers the reduced utility arising from greater complexity, while being led to believe in a false promise. Just trying to make sure I understand what you’re saying. Are you eluding to that if two of the three private keys get compromised there is no gain in security? Although the likelihood of this occurring is lower, it is possible. No, that's not it. Sorry for not being clear. Independence of control is the central issue in the analysis of a multiple factor system. If an attack compromises one factor there must be no way for that attack to reduce the difficulty of obtaining the other factors. Some factors (secrets), like a fingerprint, aren't very secret at all. But getting someone's fingerprint doesn't also help the attacker get a PIN. That factor must be attacked independently. But if the PIN is encrypted with the fingerprint in a public store, then the PIN is not independent of the fingerprint and there is really only one secret. If multiple factors are coincident (located within the same security perimeter) they are compromized coincidentally. Coincidence has the same effect as dependence. Consider a credit card with a security code printed on the back. A successful attack on the leather wallet yields both secrets. Individual environments can be compromised with some difficulty (e.g. desktop malware, fingerprint lift, dictionary attack, brute force PIN, etc.). For the sake of simplicity, let that chance of successful independent attack on any factor be 1 in 2 and the resulting probability of successful concurrent attack on any n factors be 1 in 2^n. If m factors are dependent/coincident on others the relation becomes 1 in 2^(n-m). Any multi-factor web wallet that handles the user's keys in the browser and authenticates the user in the browser to authorize service signing is effectively single factor. One attack may be launched by an insider, or externally, against the web app, executing in the browser, gaining coincident access to two secrets. Browser/desktop malware can accomplish the same. The difficulty is 1 in 2 vs. the expected 1 in 4. As more malware targets bitcoins I think the utility is evident. Given how final Bitcoin transactions are, I think it’s worth trying to find methods to help verify those transactions (if a user deems it to be high-risk enough) before the transaction is completed. The balance is trying to devise something that users do not find too burdensome. I'm not questioning the motive, I agree it's worth trying. But trying is not succeeding. Increasing user (and/or system) complexity without increasing integrity or privacy is a poor trade, and worse if the user is misled. e signature.asc Description: OpenPGP digital 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
We're way ahead of you guys ;) https://www.bitcoinauthenticator.org/ https://www.bitcoinauthenticator.org/ - does this already, currently in alpha I’m just late to the party I guess. Thanks for the links. -- 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
Do you have anything that is NOT some web application? Bitcoin Authenticator is a desktop app+mobile app pair. It pairs with your phone over wifi, cloud push, maybe Bluetooth as well. I forget exactly. It's done in the same way as Lighthouse, so it runs Win/Mac/Linux on desktop and Android on mobile. It could be adapted to use BitGo as a third party key holder with SMS authenticator relatively easily, I think. We did the bulk of all the needed work last year as part of the bitcoinj multisig work. Then you'd have a server involved, but not a web app. -- 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
Bitcoin Authenticator is a desktop app+mobile app pair. It pairs with your phone over wifi, cloud push, maybe Bluetooth as well. I forget exactly. It's done in the same way as Lighthouse, so it runs Win/Mac/Linux on desktop and Android on mobile. It could be adapted to use BitGo as a third party key holder with SMS authenticator relatively easily, I think. We did the bulk of all the needed work last year as part of the bitcoinj multisig work. Then you'd have a server involved, but not a web app. I really like the concept of Bitcoin Authenticator and think it’s exactly what I was describing (without a third-party). I think it’s a bit confusing when they describe Bitcoin Authenticator as 2FA. I think it may be more accurate to describe it as out of band transaction verification/signing or dual transaction signing. Regardless, it’s very exciting to see others are thinking about this too. 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
Re: [Bitcoin-development] Proposal to address Bitcoin malware
In sending the first-signed transaction to another for second signature, how does the first signer authenticate to the second without compromising the independence of the two factors? Sent from my iPhone On Feb 2, 2015, at 10:40 AM, Brian Erdelyi brian.erde...@gmail.com wrote: 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] Proposal to address Bitcoin malware
Confusing or not, the reliance on multiple signatures as offering greater security than single relies on the independence of multiple secrets. If the secrets cannot be shown to retain independence in the envisioned threat scenario (e.g. a user's compromised operating system) then the benefit reduces to making the exploit more difficult to write, which, once written, reduces to no benefit. Yet the user still suffers the reduced utility arising from greater complexity, while being led to believe in a false promise. On Feb 2, 2015, at 11:35 AM, Brian Erdelyi brian.erde...@gmail.com wrote: Bitcoin Authenticator is a desktop app+mobile app pair. It pairs with your phone over wifi, cloud push, maybe Bluetooth as well. I forget exactly. It's done in the same way as Lighthouse, so it runs Win/Mac/Linux on desktop and Android on mobile. It could be adapted to use BitGo as a third party key holder with SMS authenticator relatively easily, I think. We did the bulk of all the needed work last year as part of the bitcoinj multisig work. Then you'd have a server involved, but not a web app. I really like the concept of Bitcoin Authenticator and think it’s exactly what I was describing (without a third-party). I think it’s a bit confusing when they describe Bitcoin Authenticator as 2FA. I think it may be more accurate to describe it as out of band transaction verification/signing or dual transaction signing. Regardless, it’s very exciting to see others are thinking about this too. 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] Proposal to address Bitcoin malware
In sending the first-signed transaction to another for second signature, how does the first signer authenticate to the second without compromising the independence of the two factors? Not sure what you mean. The idea is the second factor displays the transaction and the user confirms it matches what they input to the first factor. Ideally, using BIP70, but I don't know if BA actually uses that currently. It's the same model as the TREZOR, except with a desktop app instead of myTREZOR and a phone instead of a dedicated hardware device. -- 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
I think what he is saying is that there is no point in having three signatures if they are not segregated in a secure manner. This is to say, if you use your computer as one factor, and a third party website as another, but you use the same computer to access the website, there is no gain in security. Another example would be an android phone. If your computer is compromised and your browser is authenticated to your Google account, you could remotely install an app on your phone. I don't know if I understood/explained myself correctly; I think two factor is better than one and there is a security gain if implemented securely. Cheers! Pedro On 2/3/2015 8:58 AM, Brian Erdelyi wrote: Confusing or not, the reliance on multiple signatures as offering greater security than single relies on the independence of multiple secrets. If the secrets cannot be shown to retain independence in the envisioned threat scenario (e.g. a user's compromised operating system) then the benefit reduces to making the exploit more difficult to write, which, once written, reduces to no benefit. Yet the user still suffers the reduced utility arising from greater complexity, while being led to believe in a false promise. Just trying to make sure I understand what you’re saying. Are you eluding to that if two of the three private keys get compromised there is no gain in security? Although the likelihood of this occurring is lower, it is possible. As more malware targets bitcoins I think the utility is evident. Given how final Bitcoin transactions are, I think it’s worth trying to find methods to help verify those transactions (if a user deems it to be high-risk enough) before the transaction is completed. The balance is trying to devise something that users do not find too burdensome. 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] Proposal to address Bitcoin malware
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
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 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
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
Re: [Bitcoin-development] Proposal to address Bitcoin malware
Martin, Yes, the second signing could be done by a mobile device that I owned and controlled (I wasn't thinking that initially). I was thinking that online services are popular because of convenience and there should be a better way to address security (privacy issues not withstanding). I think these are practical approaches and just doing a sanity check. Thanks for the vote of confidence. Brian Erdelyi Sent from my iPad On Feb 2, 2015, at 1: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. 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
