Pages:
Author

Topic: Elliptic curve math question (Read 14045 times)

sr. member
Activity: 437
Merit: 415
1ninja
January 10, 2012, 11:06:54 PM
The end result?  Pretty much bulletproof paper wallet.  Nobody can steal the funds!  Not even if I decide to be a crook, or if they produce their paper wallet on a filthy rooted pwned machine.

Well, if it's really filthy rooted pwned, with an attack that is aware of bitcoins and how this system/site works, the malware could just replace the real pubkeys/addresses on the paper wallet that's being generated so that instead of corresponding to the combo of private keys, just corresponds to a private key the attacker controls. It'll stop a generic packet or key logger or the like, but if you really can't trust your computation device, then I don't see how you can trust that your output is right.

We are discussing degrees of security or probability of encountering an attack. The easier an attack is the more likely it will occur.

Sorry... in other words Casascius is "raising the stakes".

To be properly paranoid you could take the list of public keys from Casascius along with the private keys you generated on the pwned machine using the bitaddress-like service and re-run them through the bitaddress-like service on a different computer to double check the calculation of the combined bitcoin address.

I think this novel idea can significantly increase the security of paper wallets against malware, especially once bitcoin goes mainstream.

pc
sr. member
Activity: 253
Merit: 250
January 08, 2012, 09:07:17 PM
The end result?  Pretty much bulletproof paper wallet.  Nobody can steal the funds!  Not even if I decide to be a crook, or if they produce their paper wallet on a filthy rooted pwned machine.

Well, if it's really filthy rooted pwned, with an attack that is aware of bitcoins and how this system/site works, the malware could just replace the real pubkeys/addresses on the paper wallet that's being generated so that instead of corresponding to the combo of private keys, just corresponds to a private key the attacker controls. It'll stop a generic packet or key logger or the like, but if you really can't trust your computation device, then I don't see how you can trust that your output is right.
legendary
Activity: 873
Merit: 1000
January 05, 2012, 04:36:46 PM
This text file contains the pubkeys for all the privkeys on the page.

to make sure that i understand this better, please clarify this.  re-running the bitaddress-like service against the same text file will create different bitcoin addresses, right?  i.e., the output of the bitaddress-like service is non-deterministic?
vip
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
January 02, 2012, 04:44:07 PM
So here's how that might work.

  • I sell a "half paper wallet" on my website.
  • Each half paper wallet has 7 QR coded private keys, they are individual stickers.  Each sticker has a short ID code (maybe 8 characters) that ensures they place the right sticker on the right place on their final paper wallet.  The ID code is based on the hash of the pubkey, but isn't a bitcoin address (to avoid confusion).
  • The product also shows a URL, example, casascius.com/pw/9F281BCA398D.txt.  There is one URL per sheet sold.  This text file contains the pubkeys for all the privkeys on the page.
  • A service, conceptually similar to BitAddress.org, will http get that file (or offer a place to paste it, if network access is disallowed), and use the pubkeys to construct the paper wallet.  Each address on the paper wallet will have a spot to place my stickers.  It will recompute the same ID numbers from the pubkeys, so the user can assure themselves they are putting their stickers in the right place

The end result?  Pretty much bulletproof paper wallet.  Nobody can steal the funds!  Not even if I decide to be a crook, or if they produce their paper wallet on a filthy rooted pwned machine.
vip
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
January 02, 2012, 04:35:00 PM
Mike,

The two party scheme I think you are working on should be:

Code:
A has private key a and sends public key a*G to B [scalar mult]
B has private key b and calculates new public key b*(a*G) from public key a*G [scalar mult]

Ending private key is b*a (simple modulo multiplication)
  But not known to either A or B, only knowable by someone once they have both a and b
Ending public key is b*a*G

This makes sense, and is what I was looking for.  Thanks!

I wanted to experimentally create a service where I am "B" and mail out stickers to stick on paper wallets produced by (or printed from website) A.  My sticker would have a second private key and the combined Bitcoin address.

Or perhaps even better, where I am "A", and someone uses a website to print their paper wallet "B", and sticks my stickers on their page.  (That way, I'm not responsible for calculating the final Bitcoin address, which would be a potential scam vector.)
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
January 02, 2012, 04:29:45 PM
Mike,

The two party scheme I think you are working on should be:

Code:
A has private key a and sends public key a*G to B [scalar mult]
B has private key b and calculates new public key b*(a*G) from public key a*G [scalar mult]

Ending private key is b*a (simple modulo multiplication)
  But not known to either A or B, only knowable by someone once they have both a and b
Ending public key is b*a*G
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
January 02, 2012, 04:23:27 PM
You can add points together--that is the core operations of ECC math.  Scalar multiplication is just an extension of that.  If you have point P, then 5*P is just P+P+P+P+P.  There is no such thing as point-to-point mulitplication.
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
January 02, 2012, 04:18:02 PM
There is no defined multiply operation on the eliptical curve group (hence group).

Why are you trying to muliply points?
vip
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
January 02, 2012, 04:15:44 PM
OK, so random question... how do you multiply a point by a point?

I understand multiplying a point by a scalar value... but I have no concept of multiplying two points together, neither does BouncyCastle offer any function in its "point" class that multiplies the point by another point.

What am I misunderstanding?  Thanks in advance.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
December 09, 2011, 03:41:34 PM
I suppose that if I offer a two-party key scheme, I might do well not only to use multiplication, but to insist on a mutual commitment of public keys via exchanging hashes first, so that neither party has the opportunity to base their public key on the one they received.

It doesn't hurt, but I'm not sure how much it helps.  The multiplication scheme (DHSS) is used all the time with with pre-published, persistent identities/keys on the internet, all the time.  I think the point here, was, that DHSS is established and you can feel comfortable using it in the ways prescribed by NIST, etc (which doesn't recommend any precautions with respect to public key exchange).  If someone was smart enough to find a mathematical hole in DHSS based on public key exchange, then they're smart enough to realize that there are much more profitable targets to be exploited around the globe than a $3,000 casascius gold bar...

vip
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
December 09, 2011, 02:20:23 AM
Just thinking about the attack vector, realizing that E and C could be reversed.  A customer could use the same scheme to acquire an intact Casascius coin with no funds, if I were to offer to have done a two-key coin, and had acquiesced to a request to provide my intended public key first.  Having that happen would be non-amusing, so, I suppose I am appreciative to have been made aware of it before ever having produced any.

I suppose that if I offer a two-party key scheme, I might do well not only to use multiplication, but to insist on a mutual commitment of public keys via exchanging hashes first, so that neither party has the opportunity to base their public key on the one they received.
donator
Activity: 2058
Merit: 1054
December 09, 2011, 12:31:36 AM
The recently explained security flaw resulting from adding public key points to derive a common public key is the one I had in mind in my original post.

A number of forum members seemed to have convinced themselves of the security of the scheme and I hope that this episode encourages people to be less confident and more cautious about "novel" cryptographic constructions.
This isn't a problem with generating a public key from adding two other public keys, but rather with some specific applications. I for one thought we were talking about making casascius coins - if they're not manufactured according to spec all bets are off, which is why they need to be sampled anyway, which would detect attacks like the one described.

(I don't disagree with your main point though.)
sr. member
Activity: 416
Merit: 277
December 08, 2011, 09:51:20 PM
The recently explained security flaw resulting from adding public key points to derive a common public key is the one I had in mind in my original post.

A number of forum members seemed to have convinced themselves of the security of the scheme and I hope that this episode encourages people to be less confident and more cautious about "novel" cryptographic constructions.

I believe it's possible to recover the security of the scheme without resorting to a two-round system in which the hashes are published and then the public keys revealed. This is achieved as follows:

1) The participants publish the hashes (or equivalently addresses) of public keys for which signatures have been seen in the block chain.
2) The software scans the signatures in the block chain for the relevant public keys and the combined public key is formed by addition.

This scheme is secure against the attack outlined (in a somewhat garbled fashion) in this post because Ekim is unable to create signatures with the key he broadcasts (P in the post's terminology).

ByteCoin
vip
Activity: 447
Merit: 258
December 08, 2011, 06:37:17 PM
They can cross in the mail by the two sending each other the hashes of their pre-generated public keys, sharing them only after both have confirmed receipt of the hashes.

Yup.  A slight optimization allows the first party that receives a public key hash to immediately respond with his own public key, without awaiting confirmation.  Because publishing a public key is contingent on receiving a hash, it can be viewed as confirmation and commitment in one.
vip
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
December 08, 2011, 03:15:44 PM
I did think of this and thought of it this way:  If both parites send their public keys to each other at the start of the protocol and they "cross in the mail" then the system is secure because there is now agreement on which two keys are to be added together to create the final public key.

I guess there may be a way to ensure this "crossing in the mail" but what if Ekim is very clever and so on...

They can cross in the mail by the two sending each other the hashes of their pre-generated public keys, sharing them only after both have confirmed receipt of the hashes.
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
December 08, 2011, 02:52:59 PM
I did think of this and thought of it this way:  If both parites send their public keys to each other at the start of the protocol and they "cross in the mail" then the system is secure because there is now agreement on which two keys are to be added together to create the final public key.

I guess there may be a way to ensure this "crossing in the mail" but what if Ekim is very clever and so on...
vip
Activity: 447
Merit: 258
December 08, 2011, 02:21:07 PM
But what about Mike’s evil twin brother Ekim?
Again, the customer creates public key C and private key c where C = c*G
Ekim creates public key E and private key e where E = e*G
The customer sends public key C to Ekim but instead of creating the correct public key F = C + E, Ekim instead creates a pseudo public key P where C + P = E, in other words P = E - C
Ekim now transfers the BTC to the key pair he created E = e*G and ships the product to the customer along with the fake public key P and nothing under the hologram
Since the pseudo public key P was created as P = E – C the customer will be able to verify that C + P = E and also be able to verify that the BTC are stored on E, so the customer thinks that all is well!
When the time comes the customer looks under the hologram and discovers there is no key (or a bogus key) and they have been ripped off.  Ekim can move the BTC from E at any time since he knows e.

Academic observation: In this scenario, the customer is safe if Ekim commits to E before C is revealed (by publishing a hash of E, for example).
vip
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
December 08, 2011, 02:10:07 PM
I deleted it because I realized I had misunderstood.

You are right.
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
December 08, 2011, 01:24:11 PM
EDIT:  I guess this is an answer to a question that disappeared while I was answering it!  O well I will leave it here for anyone who has the same question.

The argument is subtle.  First we are not talkikng about Mike, we are talking about Ekim - and he is out to rip off the customer (being Mike's evil twin brother).

On purpose he is funding the key E (which he totally controls with the private key e).  He is planning to take the BTC back at a later time.

The plan is to lie and tell the customer that his key E is the final combined key.

To do this he calculates P = E - C and lies and tells the customer that P is his public part of the two part key chain being used to secure the BTC.  Liar - he does not even know the private key for P (and can't)!

So everything is set up.  Ekim ships the item to the customer claiming that P is his public key and claims to have put the corresponding private key p under the hologram.  He has not since he does not even know p.  He also lies and says that E is the final combined key.

The customer gets the item and the two public keys P and E.  The customer is sophisticated and careful so they check everything out.

First they check to make sure the BTC they ordered are on the combined key.  He looks in the block chain for key E and yes the BTC are there.

Next he wants to make sure that the public keys add up so he calculated C + P and yes it does equal E!

So the customer is happy and thinks everything is ok - but it is not.  Ekim controls the BTC and the customer has no way to get the BTC.

vip
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
December 08, 2011, 12:11:48 PM
I don't have any significant efforts invested into addition that cannot be easily switched to multiplication, so this should not be a problem with respect to my coins.

I expect that to create two-part physical bitcoins, I would simply take private key circles out of my secure repurposed Nutella jar, use the series 1 hologram which covers it entirely, calculate the composite bitcoin address, and laser the resulting address on the outside of the hologram.  That's time consuming, but not unreasonable for the gold coin since there won't be that many of them.
Pages:
Jump to: