Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys

[Gregory Maxwell]

On Sat, Mar 8, 2014 at 11:34 AM, Luke-Jr  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=122218951&iu=/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)

[Alan Reiner]

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 > > wrote:
>>  
>>
>> I create a new keypair,  with  which I know (it
>> can be any arbitrary key pair).  But I don't give you , I
>> give you   =  minus  (which I can do because
>> I've seen  before doing this). 
>>
>> Sure, I don't know the private key for , but it doesn't
>> matter... because what
>>
>>  +  =  (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=122218951&iu=/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=122218951&iu=/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=122218951&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin wiki is down

[Gregory Maxwell]

On Sat, Mar 8, 2014 at 12:59 PM, Tom Geller  wrote:
> Just an FYI: The Bitcoin wiki (https://en.bitcoin.it) is down.
>
> Is there a communication procedure or point person for such things?

This works.  The wiki is in the process of changing control/operation.
Nothing to fear.

--
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=122218951&iu=/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

[Tom Geller]

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=122218951&iu=/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)

[Alan Reiner]

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  > wrote:
>  
>
> I create a new keypair,  with  which I know (it can
> be any arbitrary key pair).  But I don't give you , I give
> you   =  minus  (which I can do because I've
> seen  before doing this). 
>
> Sure, I don't know the private key for , but it doesn't
> matter... because what
>
>  +  =  (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=122218951&iu=/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=122218951&iu=/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

[Luke-Jr]

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=122218951&iu=/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

[Gustav Simonsson]

While there is no mention of virtualization in the side-channel article,
the FLUSH+RELOAD paper [1] mentions virtualization and claims the clflush
instruction works not only towards processes on the same OS, but also
against processes in a separate guest OS if executed on the host OS (type 2
hypervisor) [2]. It also works if executed from within another guest OS
(though that reduces the efficiency of the attack) [3].

Both the authors [4] and Vulnerability Note VU#976534 [5] claim disabling
hypervisor memory page de-duplication prevents the attack. This could
perhaps be a first step for bitcoin companies running their software on
shared hosts; demand their allocated instances to be on hosts with this
disabled. Question is how common it is for virtualization providers to
offer that as an option.

TRESOR is is only applicable if running in a non-virtualized OS [6].

While TRESOR only implements AES, it seems it could work for ECDSA as well,
as they use the four x86 debug registers to fit a 256 bit privkey [7] for
the entire machine uptime, and then use other registers when doing the
actual AES ops. They use the Intel AES-NI instruction set though, and since
there is no corresponding instruction set for EC extra work would be
required to manually implement EC math in assembler.

They actually do what Mike Hearn mentioned and disable preemption in Linux
(their code runs in kernel space; they patched the kernel) to ensure
atomicity. Not only do they manage to protect against memory attacks (and
RAM/cache timing attacks) from other processes running on the same host,
but even from root on the same host (from userland, the debug registers are
only accessible through ptrace, which they patched, and they also disabled
LKM & KMEM).

One could imagine different levels of TRESOR-like ECDSA with different
tradeoffs of complexity vs security. For example, if one is fine with
keeping the privkey(s) in RAM but want to avoid cache timing attacks, the
signing could be implemented as a userspace program holding key(s) in RAM
together with a kernel module providing a syscall for signing. Signing is
then run with preemption using only x86 registers for intermediate data and
then using e.g. movntps [8] to write to RAM without data being cached. The
benefit of this compared with the full TRESOR approach is that it would not
require a patched kernel, only a kernel module. It would also be simpler to
implement compared to keeping the privkey in the debug registers for the
entire machine uptime, especially if multiple privkeys are used. It would
not protect against root though, since an adversary getting root could load
their own kernel module and read the registers.

To handle multiple keys (maybe as one-time-use) and get full TRESOR
benefits, one could perhaps (with the original TRESOR approach, i.e. with
patched kernel) store a BIP 0032 starting string / seed + counter in the
debug registers and have the atomic kernel code generate new keys and do
the signing.

Cheers,
Gustav Simonsson

1. http://eprint.iacr.org/2013/448.pdf
2. Page 1 of [1]
3. page 5 of [1]
4. page 8 (end of conclusions section) of [1]
5. http://www.kb.cert.org/vuls/id/976534
6. page 8, "3.2 Hardware compatibility",
https://www.usenix.org/legacy/event/sec11/tech/full_papers/Muller.pdf
7. page 3, "2.2 Key Management" of [6]
8. page 1041 of
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf



On Thu, Mar 6, 2014 at 9:38 AM, Mike Hearn  wrote:

> I'm wondering about whether (don't laugh) moving signing into the kernel
> and then using the MTRRs to disable caching entirely for a small scratch
> region of memory would also work. You could then disable pre-emption and
> prevent anything on the same core from interrupting or timing the signing
> operation.
>
> However I suspect just making a hardened secp256k1 signer implementation
> in userspace would be of similar difficulty, in which case it  would
> naturally be preferable.
>
>
> On Wed, Mar 5, 2014 at 11:25 PM, Gregory Maxwell wrote:
>
>> On Wed, Mar 5, 2014 at 2:14 PM, Eric Lombrozo 
>> wrote:
>> > Everything you say is true.
>> >
>> > However, branchless does reduce the attack surface considerably - if
>> nothing else, it significantly ups the difficulty of an attack for a
>> relatively low cost in program complexity, and that might still make it
>> worth doing.
>>
>> Absolutely. I believe these things are worth doing.
>>
>> My comment on it being insufficient was only that "my signer is
>> branchless" doesn't make other defense measures (avoiding reuse,
>> multsig with multiple devices, not sharing hardware, etc.)
>> unimportant.
>>
>> > As for uniform memory access, if we avoided any kind of heap
>> allocation, wouldn't we avoid such issues?
>>
>> No. At a minimum to hide a memory timing side-channel you must perform
>> no data dependent loads (e.g. no operation where an offset into memory
>> is calculated). A strategy for this is t

[Bitcoin-development] New IRC name: aschildbach

[Andreas Schildbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I just renamed myself on IRC (freenode) to aschildbach. The old name
was Goonie. I will most likely only use the new name from now on, at
least for Bitcoin-related purposes (-:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iEYEARECAAYFAlMbarAACgkQymYr4YuHemCjRwCgmjiod+yXeUg5Mtn83k9pXY9U
rfAAoMxBaNL0e+BuGSXWDCrAtb+77w69
=UhVB
-END PGP SIGNATURE-


--
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=122218951&iu=/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)

[Natanael]

You can always use a secure multiparty computation algorithm to do it.

https://en.wikipedia.org/wiki/Secure_multi-party_computation

But those aren't the fastest algorithms in the world, and usually both
participants needs to be online at the same time. I guess most people would
prefer a two-step algorithm that can be performed asynchronously.

- Sent from my phone
Den 8 mar 2014 18:44 skrev "Adam Back" :

> 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=122218951&iu=/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=122218951&iu=/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)

[Adam Back]

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=122218951&iu=/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)

[Joel Kaartinen]

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  > wrote:
>  
>
> I create a new keypair,  with  which I know (it can
> be any arbitrary key pair).  But I don't give you , I give
> you   =  minus  (which I can do because I've
> seen  before doing this). 
>
> Sure, I don't know the private key for , but it doesn't
> matter... because what
>
>  +  =  (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=122218951&iu=/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=122218951&iu=/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

[Jan Vornberger]

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=122218951&iu=/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)

[Edmund Edgar]

On 8 March 2014 17:10, Alan Reiner  wrote:


> I create a new keypair,  with  which I know (it can be any
> arbitrary key pair).  But I don't give you , I give you   =
>  minus  (which I can do because I've seen  before
> doing this).
>
> Sure, I don't know the private key for , but it doesn't matter...
> because what
>
>  +  =  (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=122218951&iu=/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)

[Alan Reiner]

On 03/08/2014 01:55 AM, Edmund Edgar wrote:
> On 4 March 2014 14:07, Odinn Cyberguerrilla
>  > wrote:
>
> Nothing is safe.
>
>
> This is true. To rephrase, imagine I gave you an ECC public key
> , you gave me back a public key  of your own
> devising, then I paid some money to the address resulting from
> add_pubkeys(,) [1]. Can anyone either:
>
> a) Think of a way that Odinn could make an  such that they
> could spend the resulting money without having .
> b) Opine, somewhat knowledgeably, that this probably wouldn't be an
> easy thing to do, and they wouldn't be alarmed to see people running
> software that did this kind of thing.
>
> [1] 
> https://github.com/vbuterin/pybitcointools/blob/master/pybitcointools/main.py#L173

Consider that I see your public key  before I create and send you
my public key .

I create a new keypair,  with  which I know (it can be
any arbitrary key pair).  But I don't give you , I give you 
 =  minus  (which I can do because I've seen
 before doing this). 

Sure, I don't know the private key for , but it doesn't matter...
because what

 +  =  (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)

-Alan
--
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=122218951&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development