[Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware
An idea for the bitcoin malware proposal below, the idea is at the bottom… Using a desktop website and mobile device for 2/3 multisig in lieu of a hardware device (trezor) and desktop website (mytrezor) works, but the key is that the device used to input the two signatures cannot be in the same band. What you are protecting against are MITM attacks. The issue is that if a single device or network is compromised by malware, or if a party is connecting to a counterparty through a channel with compromised security, inputing 2 signatures through the same device/band defeats the purpose of 2/3 multisig. This is the same as how MITM defeats 2FA via mobile phone if the token is entered into the same website as the password - the token is simply passed through by the attacker to the secure session with the provider, allowing unfettered access or reuse of tokens for transactions other than those intended by the real user. Companies have found clever ways around MITM attacks using SSL sniff and derivatives by embedding code in mobile apps that communicate not with the website authenticating the user, but with 3rd party company that authenticates the token and passes the authentication to the website through a different secure channel, making the MITM attack far much more difficult. The trick here is that instead of one channel, we now have two channels that must be compromised. Also, the second channel is between a security company and a (hopefully) professionally run financial services website. There are other approaches to defeat MITM, such as fingerprinting pages to detect spoofs. The former (secure 3rd party channel) is very secure but requires a trusted third party. The latter (fingerprinting) is a crap shoot with very high false positive rates. Anyway, the exact same principles apply here to this conversation. The second signature must be presented from a separate band to maintain a higher degree of security. If one signature occurs via HTTP(s) from application 1, another should be SMS through a carrier network, etc via application 2. The trick we need to look at is how to use the bitcoin network as a delivery mechanism to bypass the need for the trusted third party in the example above. Instead of the second factor routing through a 3rd party to the intended recipient, we have another option - one that doesn’t require core development either. 1) Sender signs signature 1 via desktop bitcoin network 2/3 P2SH 2) Mobile app also used by sender receives req. from bitcoin network to sign signature - not through the site in 1 (similar to the 2nd channel between the website and security company above) 3) Sender signs signature 2 via mobile app (or any separate device operating on a different network - heck could be radio) 2/3 signatures, transaction authorized Any wallet service provider can use this model, all they must do is develop two independent applications such a secure browser plugin and a website, or a mobile app and a website that use 2/3 multisig to authorize transactions. No core development required - just better security design and execution by those developing wallets. If the protocol could natively communicate via two separate networks, that might be something to consider, but really developers should already have all the tools they need, assuming they are competent. If there was a way to perform 2/3 multisig without requiring a second band, performing the function safely by somehow knowing if the service is performed from a compromised device through some sort of on-blockchain anti-malware check by validating the signature of the signing application by comparing it to a signature recorded when the multisig address was funded, that would be a really neat breakthrough. Food for thought, but I can’t see how that could be executed in a way where signatures couldn’t be spoofed from a compromised device. If someone cracks that problem, it’s a really big advance for information security. 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
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
Could we see a PR that adds it to BIP 66? Perhaps we'd all agree quickly that its so simple we can just add it... In either case it doesn't seem strictly necessary to me that it was non-standard before it becomes a soft-fork... On Tue, Feb 3, 2015 at 7:00 AM, Wladimir laa...@gmail.com wrote: 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? Not opposed, but is kind of late for 0.10, I had hoped to tag rc4 today. 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 -- 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
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? Not opposed, but is kind of late for 0.10, I had hoped to tag rc4 today. 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 4:00 AM, Wladimir laa...@gmail.com wrote: 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? Not opposed, but is kind of late for 0.10, I had hoped to tag rc4 today. I understand it's late, which is also why I ask for opinions. It's also not a priority, but if we release 0.10 without, it will first need a cycle of making this non-standard, and then in a further release doing a second softfork to enforce it. It's a 2-line change; see #5743. -- 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] [softfork proposal] Strict DER signatures
I think we should just do it, and include it with the other DERSIG changes for 0.10. On Tue, Feb 3, 2015 at 1:15 PM, Pieter Wuille pieter.wui...@gmail.com wrote: I understand it's late, which is also why I ask for opinions. It's also not a priority, but if we release 0.10 without, it will first need a cycle of making this non-standard, and then in a further release doing a second softfork to enforce it. It's a 2-line change; see #5743. -- Pieter -- -- 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] [softfork proposal] Strict DER signatures
+1 I just ran an it-works test on #5743. Not exhaustive, but I do agree it should be included w/ other DERSIG changes. On Tue, Feb 3, 2015 at 1:19 PM, Gavin Andresen gavinandre...@gmail.com wrote: I think we should just do it, and include it with the other DERSIG changes for 0.10. On Tue, Feb 3, 2015 at 1:15 PM, Pieter Wuille pieter.wui...@gmail.com wrote: I understand it's late, which is also why I ask for opinions. It's also not a priority, but if we release 0.10 without, it will first need a cycle of making this non-standard, and then in a further release doing a second softfork to enforce it. It's a 2-line change; see #5743. -- Pieter -- -- 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 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] Subject: Re: Proposal to address Bitcoin malware
Using a desktop website and mobile device for 2/3 multisig in lieu of a hardware device (trezor) and desktop website (mytrezor) works, but the key is that the device used to input the two signatures cannot be in the same band. What you are protecting against are MITM attacks. The issue is that if a single device or network is compromised by malware, or if a party is connecting to a counterparty through a channel with compromised security, inputing 2 signatures through the same device/band defeats the purpose of 2/3 multisig. Maybe I'm not following the conversation very well, but if you have a small hardware device that first displays a signed payment request (BIP70) and then only will sign what is displayed, how can a MITM attacker do anything other than deny service? They'd have to get malware onto the signing device, which is the vector that a simplified signing device is specifically designed to mitigate. TREZOR like devices with BIP70 support and third party cosigning services are a solution I really like the sound of. I suppose though that adding BIP70 request signature validation and adding certificate revocation support starts to balloon the scope of what is supposed to be a very simple device though. Regardless, I think a standard for passing partially signed transactions around might make sense (maybe a future extension to BIP70), with attention to both PC - small hardware devices and pushing stuff around on the Internet. It would be great if users had a choice of hardware signing devices, local software and third-party cosigning services that would all interoperate out of the box to enable easy multisig security, which in the BTC world subsumes the goals of 2FA. --adam -- 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] Subject: Re: Proposal to address Bitcoin malware
Hi Adam - the conversation was pretty open regarding the factor / channel used to sign at the bottom. No argument from me and I agree completely that hardened single purpose computers are more secure than desktop browsers, browser extensions, SMS, or mobile apps when involved in multisig authorization. The point below was that risks with other channels are far higher if auth data is input from two channels through one, such as entering a 2FA phone token and desktop password into the same desktop browser session - MITM phishing attack on websites that bypasses phone 2FA as an example, serendipitously timed yet tragic example of this scam with coinbase today: https://www.reddit.com/r/Bitcoin/comments/2ungby/fuck_i_just_got_scammed/ On the topic of hardened single purpose computers, and I mean no offense to our friends at Trezor, Case, or similar but I think the future of this type of security approach with bitcoin is extremely bright. It’s just far more likely to involve chips integrated directly in PC / Mac motherboards and mobile devices / wearables where signing is done in the hardware inaccessible to the OS or BIOS. This is a way for mainstream users to use bitcoin securely, integrate it with apps running from popular OS’s and get bitcoin into the internet on a very granular level, and Joe six pack and Sally soccer mom never even know they are using multisig. It took 20+ years for people to get used to cards vs. cash. The telephone took 50 years to catch on and become cost competitive. I think the key is making it invisible to the user. From: Adam Weiss a...@signal11.com Reply: Adam Weiss a...@signal11.com Date: February 3, 2015 at 12:25:20 PM To: Will will.mad...@novauri.com Cc: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware Using a desktop website and mobile device for 2/3 multisig in lieu of a hardware device (trezor) and desktop website (mytrezor) works, but the key is that the device used to input the two signatures cannot be in the same band. What you are protecting against are MITM attacks. The issue is that if a single device or network is compromised by malware, or if a party is connecting to a counterparty through a channel with compromised security, inputing 2 signatures through the same device/band defeats the purpose of 2/3 multisig. Maybe I'm not following the conversation very well, but if you have a small hardware device that first displays a signed payment request (BIP70) and then only will sign what is displayed, how can a MITM attacker do anything other than deny service? They'd have to get malware onto the signing device, which is the vector that a simplified signing device is specifically designed to mitigate. TREZOR like devices with BIP70 support and third party cosigning services are a solution I really like the sound of. I suppose though that adding BIP70 request signature validation and adding certificate revocation support starts to balloon the scope of what is supposed to be a very simple device though. Regardless, I think a standard for passing partially signed transactions around might make sense (maybe a future extension to BIP70), with attention to both PC - small hardware devices and pushing stuff around on the Internet. It would be great if users had a choice of hardware signing devices, local software and third-party cosigning services that would all interoperate out of the box to enable easy multisig security, which in the BTC world subsumes the goals of 2FA. --adam -- 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 10:15 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? I'm retracting this proposed change. Suhar Daftuas pointed out that there remain edge-cases which are not covered (a 33-byte R or S whose first byte is not a zero). The intent here is really making sure that signature validation and parsing can be entirely separated, and that signature checking itself does not need a third return value (invalid encoding, in addition to valid signature and invalid signature). If we don't want to make assumptions about how that implementation works, the only guaranteed way of doing that is requiring that R and S are in fact within the range allowed by secp256k1, which would require an integer decoder inside the signature encoding checker. I consider that to be unreasonable. In addition, a much cleaner solution that covers this as well has already been proposed: only allow 0 (the empty byte vector) as invalid signature. That would 100% align signature validity with decoding, and is much simpler to implement. -- 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] Subject: Re: Proposal to address Bitcoin malware
TREZOR like devices with BIP70 support and third party cosigning services are a solution I really like the sound of. I suppose though that adding BIP70 request signature validation and adding certificate revocation support starts to balloon the scope of what is supposed to be a very simple device though. Yes, X.509 is ... unfortunate. We'll have to wait and see how the TREZOR team get on with implementing it. TREZOR doesn't have any OS at all at the moment, so an implementation of PKIX will probably end up being larger than their existing codebase. That said, X.509 parsing is so security critical that the existing codebases for it are by now pretty robust. Touch wood. So just having a super stripped down OpenSSL implementation is probably good enough. W.R.T revocation, BIP70 doesn't support this. If your private key leaks you're currently hosed, identity wise, until the certificate expires. This is obviously suboptimal. In a world where we all have infinite time and resources the right fix will be to piggy back on an X.509 extension being proposed in the browser world called Must Staple. It's a bit in the certificate flags that tell the client to expect a stapled OCSP response and to hard-fail if none is provided. By requesting the CA set this flag when you get your certificate issued, you sign up for more pain but more security. An OCSP stapling extension to BIP70 would probably not be very hard to implement, but it'd be pointless today because the client has no idea whether to expect it or not. The absence of a certificate changes the UI by showing you a random Bitcoin address instead of a human readable name, but the absence of stapled OCSP would not result in any UI change. Regardless, I think a standard for passing partially signed transactions around might make sense I'm hoping that the hardware wallet world just standardises on the TREZOR protocol. It's well designed and these devices all have fairly similar capabilities. -- 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] Subject: Re: Proposal to address Bitcoin malware
Regardless, I think a standard for passing partially signed transactions around might make sense (maybe a future extension to BIP70), with attention to both PC - small hardware devices and pushing stuff around on the Internet. It would be great if users had a choice of hardware signing devices, local software and third-party cosigning services that would all interoperate out of the box to enable easy multisig security, which in the BTC world subsumes the goals of 2FA. I think a standard for passing partially signed transactions is a great idea as well. This would support interoperability of wallets/clients and third-party services (if users choose to use them). 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] Export format for xpub
Why even bother with the specific HD scheme such as BIP32 or BIP44. What are the interesting parameters? Required: - gap limit Optional: - which node of the derivation chain is actually exported (m0' for BIP32, m44'0'account' for BIP44) - which subnodes are used for external and internal purposes - creation date To import the data in a read only application it is not important which node one actually gets and in all implementations the subnode of the exported node 0 is used for external addresses and 1 for internal addresses. There is no usecase to export any higher node than m0' in BIP32 or m44'0'account' as one can only derive any child nodes of the higher nodes *with the private master key*. As for lower nodes (like further down the path) there is also no need to export because in all implementations today they will only give around half of the used addresses. So I think a more general but very useful export scheme would be: bitcoin-pub-export:xpub[gibberish]?gaplimit=[number]path=[path in derivation tree]subchains=[numbers]creationdate=[unixtimestamp] Why not have more descriptive parameters? Saving on data? I am a big fan of unix timestamps. Would vote for Andreas' format on the creation date. Cheers Levin 2015-02-03 1:22 GMT+01:00 Pavol Rusnak st...@gk2.sk: 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 -- 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/03/2015 10:33 AM, Levin Keller wrote: Why not have more descriptive parameters? Saving on data? Yes. QR codes are very size sensitive. -- 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 03/02/15 11:37, Andreas Schildbach wrote: Not really IMHO. Keys can be used on multiple blockchains. Ah, correct. Timestamp it is. Nitpick: They cannot be used on multiple blockchains according to BIP32. In BIP43 we fixed that. :-) -- 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/03/2015 01:22 AM, Pavol Rusnak wrote: Hm, let me put the questions the other way around: What gap limit should a wallet use if it encounters h=bip32? It should follow the spec. I know BIP32-hierarchy is short on gap limits, which is why (amongst other reasons) I expect BIP32-hierarchy-based wallets migrate to a better standard at some time. What h value should I use for myTREZOR wallets? Which is essentially a BIP44 wallet that produces h=bip32 xpubs with gap limit 20 ... If it follows BIP32, h=bip32 is fine. -- 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/03/2015 11:10 AM, Pavol Rusnak wrote: Another option that might make sense is the block number. Not really IMHO. Keys can be used on multiple blockchains. -- 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] Subject: Re: Proposal to address Bitcoin malware
On 02/03/2015 04:04 AM, Will wrote: An idea for the bitcoin malware proposal below, the idea is at the bottom… ... The trick we need to look at is how to use the bitcoin network as a delivery mechanism to bypass the need for the trusted third party in the example above. Using the Bitcoin network would be a convenience, certainly not a requirement. Any public store (or other channel accessible to all signers) would do. Instead of the second factor routing through a 3rd party to the intended recipient, we have another option - one that doesn’t require core development either. Absolutely, there is no need for a trusted third party in the case of MFA unless that party has independent judgement in the decision to sign. For example, if the third party is the trustee of a fund from which a beneficiary wants to withdraw. If you are just routing a decision back to yourself a third party makes no sense. Oddly most of the services in operation today are doing just that. You will end up authenticating to the third party from a platform you control, which means that the platform must be trusted as much as the third party. Why not just trust the platform and no third party? It doesn't reduce the number of factors but it certainly reduces the attack surface. 1) Sender signs signature 1 via desktop bitcoin network 2/3 P2SH 2) Mobile app also used by sender receives req. from bitcoin network to sign signature - not through the site in 1 (similar to the 2nd channel between the website and security company above) 3) Sender signs signature 2 via mobile app (or any separate device operating on a different network - heck could be radio) 2/3 signatures, transaction authorized There's no need for the devices to be on independent networks. You can safely remove that constraint. The partially-signed transaction can be encrypted to the other signatories (for privacy) or it can be sent in the clear. And ultimately all platforms in the scheme are connected to the Internet, even if it's via sneakernet. The important requirement is that the signing platforms are independent and that the signers inspect the transactions on those platforms. This preserves the benefit of MFA, which is that the signing platforms must be compromised independently. ... If there was a way to perform 2/3 multisig without requiring a second band, performing the function safely by somehow knowing if the service is performed from a compromised device through some sort of on-blockchain anti-malware check by validating the signature of the signing application by comparing it to a signature recorded when the multisig address was funded, that would be a really neat breakthrough. Food for thought, but I can’t see how that could be executed in a way where signatures couldn’t be spoofed from a compromised device. If someone cracks that problem, it’s a really big advance for information security. Once you've done this you are talking about two independent signing platforms. Plug two trustworthy signing devices into a PC and you've done it. This is because the host environment (the PC in this case) is not trusted in the first place. Two untrusted environments are no better than one. It's only if the environments are trusted that they must be independent. But therein lies the problem. The physical proximity of two trusted hardware devices exposes them to a single attack in the case of physical theft or loss. So to guard against that threat the devices must be independently stored. This presents a problem when it comes to usage. This is the central problem of MFA. It's not possible to control multiple factors while not exposing them to compromise. This is true whether we are talking about multiple physical devices or a remote service, since in the remote case the secret must still be accessible to the person in control. In the case of truly independent decisions MFA is strongest. But short of that there's no reason for a remote third party. One can probably accept the risk of securing multiple devices with the home, etc - and needs to do this even if using a third party. On the other hand, walking around with all necessary factors, or keeping them in the same safe, is tantamount to having just one factor. e On 02/02/2015 02:54 PM, Eric Voskuil wrote: On Feb 2, 2015, at 11:53 AM http://airmail.calendar/2015-02-02%2011:53:00%20MST, 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
Re: [Bitcoin-development] Export format for xpub
On 03/02/15 10:33, Levin Keller wrote: bitcoin-pub-export:xpub[gibberish]?gaplimit=[number]path=[path in derivation tree]subchains=[numbers]creationdate=[unixtimestamp] I cannot come up with an usecase where path parameter would be needed. FWIW childnumber and depth are already expressed in xpub itself. I like the general idea of subchains parameter, but I would like to further specify it: a) parameter should contain values described as comma separated list of values (such as 0,1,2,3,4) b) consecutive values can be shortened via dash (0,1,2,3 == 0-3) c) should we allow non-consecutive values (e.g. 0,1,3,8)? I am not sure. If not the subchains param can contain just upper bound of indexes to scan (e.g. 3) d) a wallet uses just the first specified chain to generate receiving addresses, uses the other chains just to add to the balance OR should a wallet be able to generate receiving address for second, third, etc. external chain? if yes, we should split subchains param into external and internal params both containing a list of numbers. this seems like an overkill to me and I am fine with using just the first chain as the external one. Why not have more descriptive parameters? Saving on data? Yes. The longer the string, the bigger the QR code. I am a big fan of unix timestamps. Would vote for Andreas' format on the creation date. I am not against Unix timestamps, I just said I expected something else there. Unix timestamps have a lot of advantages. Another option that might make sense is the block number. -- 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
