Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)
On 8 March 2014 17:10, Alan Reiner etothe...@gmail.com wrote: I create a new keypair, c_pub with c_priv which I know (it can be any arbitrary key pair). But I don't give you c_pub, I give you b_pub = c_pub minus a_pub (which I can do because I've seen a_pub before doing this). Sure, I don't know the private key for b_pub, but it doesn't matter... because what b_pub + a_pub = c_pub (mine) You have no way to detect this condition, because you don't know what c_pub/c_priv I created, so you can only detect this after it's too late (after I abuse the private key) Thanks Alan and Forrest, that makes sense. So to salvage the situation in the original case, we have to make sure the parties exchange their public keys first, before they're allowed to see the public keys they'll be combining them with. -- -- Edmund Edgar Founder, Social Minds Inc (KK) Twitter: @edmundedgar Linked In: edmundedgar Skype: edmundedgar http://www.socialminds.jp Reality Keys @realitykeys e...@realitykeys.com https://www.realitykeys.com -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
On Thu, Mar 06, 2014 at 02:39:52PM +, Alex Kotenko wrote: Not sure if you've seen it, but here is how we do NFC right now http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal. Very interesting, thanks for sharing! Are the two devices on the same wifi network in the demo? In my experience transaction propagation through the Bitcoin network takes a couple of seconds longer on average, so I'm surprised it's that fast here. You probably share this view, but I just wanted to repeat, that from my experiments, I think that sending the transaction only over the Bitcoin network should be a rarely-used fallback. It usually takes a little longer than you would like for a POS solution and every so often you don't get the transaction at all until the next block. And then what do you do? Maybe you would need to ask the customer to pay again, to get things done now, and put the previous transaction in some kind of refund mode, where - when you finally get it - you send it back somewhere. But it's really a problematic corner case - but yet it will happen occasionally with network-only propagation. In the context of this discussion, I would also like to share a video of a prototype system: https://www.youtube.com/watch?v=mguRpvf3aMc Here shown is the (currently no longer working) Bridgewalker client, but it is also fully compatible with Andreas' wallet. The client picks up the payment details via NFC (as a Bitcoin URI - could and should be updated to use payment protocol) and transmits a copy of the transaction via Bluetooth (using the simple convention first implemented by Andreas). One optimization I did in the Bridgewalker client is, that it already opens the Bluetooth connection when presenting the user with the confirmation dialog. This results in a little additional speed-up, as the connection is already warmed up, when the user confirms. All code of this prototype is open source, as is the Bridgewalker client. From my testing, I can say that NFC for getting the payment details + Bluetooth for transmitting the transaction back works well. I'm a bit skeptical about using NFC also for the back-channel, but maybe for cases where there is no additional user confirmation it could work. One problem with Bluetooth I see is, that it seems to be mostly turned off by users and many seem to perceive it as insecure, to have it active, as a result of earlier Bluetooth hacks. So I'm not sure if that will turn out to be a problem for usability when rolled-out in practice. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)
If both parties insist on seeing a hash of the other party's public key before they'll show their own public key, they can be sure that the public key is not chosen based on the public key they themselves presented. Although, I have to wonder, why not just use multisig? - Joel On 08.03.2014 10:51, Edmund Edgar wrote: On 8 March 2014 17:10, Alan Reiner etothe...@gmail.com mailto:etothe...@gmail.com wrote: I create a new keypair, c_pub with c_priv which I know (it can be any arbitrary key pair). But I don't give you c_pub, I give you b_pub = c_pub minus a_pub (which I can do because I've seen a_pub before doing this). Sure, I don't know the private key for b_pub, but it doesn't matter... because what b_pub + a_pub = c_pub (mine) You have no way to detect this condition, because you don't know what c_pub/c_priv I created, so you can only detect this after it's too late (after I abuse the private key) Thanks Alan and Forrest, that makes sense. So to salvage the situation in the original case, we have to make sure the parties exchange their public keys first, before they're allowed to see the public keys they'll be combining them with. -- -- Edmund Edgar Founder, Social Minds Inc (KK) Twitter: @edmundedgar Linked In: edmundedgar Skype: edmundedgar http://www.socialminds.jp Reality Keys @realitykeys e...@realitykeys.com mailto:e...@realitykeys.com https://www.realitykeys.com -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)
Also the other limitation for ECDSA is that there is no known protocol to create a signture with a+b (where keys P=aG, Q=bG, R=P+Q=(a+b)G). without either a sending its private key to b or viceversa (or both to a third party). With Schnorr sigs you can do it, but the k^-1 term in ECDSA makes a (secure) direct multiparty signature quite difficult. ps probably only 1 party needs to hash their key P=aG H(P) - - Q=bG P - Adam On Sat, Mar 08, 2014 at 12:37:30PM +0200, Joel Kaartinen wrote: If both parties insist on seeing a hash of the other party's public key before they'll show their own public key, they can be sure that the public key is not chosen based on the public key they themselves presented. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
On Wednesday, March 05, 2014 4:21:52 PM Kevin wrote: How can we patch this issue? No need, it is not an issue for Bitcoin. Properly used, there is only ever one signature per public key. Luke -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)
Note that one of the reasons why this is insecure is because EC point addition is invertible. EC-scalar multiplication is not, thus why EC Diffie-Hellman is secure even when this timing asymmetry exists. A good cryptosystem doesn't have strange restrictions, like your public key can only be public sometimes, but needs to protected like your private key other times. If you have to worry about things like that, you're doing it wrong :) And why we always recommend sticking to well-known, well-studied operations. -Alan On 03/08/2014 03:51 AM, Edmund Edgar wrote: On 8 March 2014 17:10, Alan Reiner etothe...@gmail.com mailto:etothe...@gmail.com wrote: I create a new keypair, c_pub with c_priv which I know (it can be any arbitrary key pair). But I don't give you c_pub, I give you b_pub = c_pub minus a_pub (which I can do because I've seen a_pub before doing this). Sure, I don't know the private key for b_pub, but it doesn't matter... because what b_pub + a_pub = c_pub (mine) You have no way to detect this condition, because you don't know what c_pub/c_priv I created, so you can only detect this after it's too late (after I abuse the private key) Thanks Alan and Forrest, that makes sense. So to salvage the situation in the original case, we have to make sure the parties exchange their public keys first, before they're allowed to see the public keys they'll be combining them with. -- -- Edmund Edgar Founder, Social Minds Inc (KK) Twitter: @edmundedgar Linked In: edmundedgar Skype: edmundedgar http://www.socialminds.jp Reality Keys @realitykeys e...@realitykeys.com mailto:e...@realitykeys.com https://www.realitykeys.com -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin wiki is down
Just an FYI: The Bitcoin wiki (https://en.bitcoin.it) is down. Is there a communication procedure or point person for such things? --- Tom Geller * Oberlin, Ohio * 415-317-1805 Writer/Presenter * http://www.tomgeller.com articles, marketing, videos, user guides, books -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)
Note that one of the reasons why this is insecure is because EC point addition is invertible. EC-scalar multiplication is not, thus why EC Diffie-Hellman is secure even when this asymmetry exists. A good cryptosystem doesn't have strange restrictions, like your public key can only be public sometimes, but needs to protected like your private key other times. If you have to worry about things like that, you're doing it wrong :) -Alan On 03/08/2014 05:37 AM, Joel Kaartinen wrote: If both parties insist on seeing a hash of the other party's public key before they'll show their own public key, they can be sure that the public key is not chosen based on the public key they themselves presented. Although, I have to wonder, why not just use multisig? - Joel On 08.03.2014 10:51, Edmund Edgar wrote: On 8 March 2014 17:10, Alan Reiner etothe...@gmail.com mailto:etothe...@gmail.com wrote: I create a new keypair, c_pub with c_priv which I know (it can be any arbitrary key pair). But I don't give you c_pub, I give you b_pub = c_pub minus a_pub (which I can do because I've seen a_pub before doing this). Sure, I don't know the private key for b_pub, but it doesn't matter... because what b_pub + a_pub = c_pub (mine) You have no way to detect this condition, because you don't know what c_pub/c_priv I created, so you can only detect this after it's too late (after I abuse the private key) Thanks Alan and Forrest, that makes sense. So to salvage the situation in the original case, we have to make sure the parties exchange their public keys first, before they're allowed to see the public keys they'll be combining them with. -- -- Edmund Edgar Founder, Social Minds Inc (KK) Twitter: @edmundedgar Linked In: edmundedgar Skype: edmundedgar http://www.socialminds.jp Reality Keys @realitykeys e...@realitykeys.com mailto:e...@realitykeys.com https://www.realitykeys.com -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
On Sat, Mar 8, 2014 at 11:34 AM, Luke-Jr l...@dashjr.org wrote: On Wednesday, March 05, 2014 4:21:52 PM Kevin wrote: How can we patch this issue? No need, it is not an issue for Bitcoin. Properly used, there is only ever one signature per public key. Security shouldn't depend on perfect use. There are many things that result in multiple key use: Bitcoin address authentication (something which the pool you created uses!), someone spamming you with multiple payments to a common address which you didn't solicit (what, are you just going to ignore the extra coins?), ... or just practical considerations— I note the mining pool you founded continually pays a single address for 'fall back' payments when it can't pay in the coinbase transact, I know you consider that a bug, but its the reality today. Most security issues aren't the result of one problem but several problems combined, so it's important to make each layer strong even if the strength shouldn't be important due to proper use in other layers. Fortunately, libsecp256k1 has a nearly constant time/constant memory access multiply for signing which should reduce exposure substantially (and is generally built in a way that reduces vulnerabilities). -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
