Topic: [ANNOUNCE] Casascius-compatible address tool for Android. - page 2. (Read 4283 times)

A few... hours or minutes you mean ? Cause i only have 1 bitcoin atm

This seems like a decent compromise until I can get QR codes working, give me a few and I'll see what I can do for ya.

This addition method has a vulnerability that allows the 2nd party to send a rigged public key that appears kosher to party 1 but permits him to steal the funds. Has been discussed in other threads. Multiplication is the only safe way to go.

The vulnerability depends on the fact that ecc addition is reversible. Ecc multiplication is not reversible and breaks the exploit.

Damnit. And if you make it a textbox ? We could easily copy the contents by long pressing it.

EDIT: 1 bitcoin going your way right now if you do it

At the moment, with your eyes and your fingers, anything else would break the "no communications with the outside world" rule of paper wallets, but I am working on making a QR code as we speak, might not get to finish it today but soon.

That could easily be a qr code as well.

How can you copy the generated priv key or address ? Please, may the answer not be "by hand" 

Nice work! Use it to cash in on my Buried Keys! Seriously though, the smartphone/brain wallet combo has so much more potential. This is a great start!

Pretty sweet!  Thanks for this.

Already on the to-do list, I'm currently poking around with the zxing QR code lib and should have something cobbled together soonish!

Even easier then, SpongyCastle (BouncyCastle for Android, because Android lacks a native ECC implementation) has ECPoint.add so all I'd need to do is add S1+S2 % order (is the order typically notated N for ECC or am I thinking of something else?)... I think... God, ECC math makes me feel like I missed an important day in high school algebra...

interesting...

Makes sense! Conveniently, I see this in BitcoinJ's implementation of ECKey.java


So now all I have to do is copypasta this over to my codebase, import all the things, then play trial and error for an hour to get it to accept pubkey #1 in place of params.getG() if I'm understanding you correctly. Oh and implement the multiplication and modulo you described for the privkeys, unless you got that math wrong, which should be pretty trivially testable.

This actually doesn't work very well. But a very slight change makes it work perfectly:

1) The first party generates a private key (S1) and a corresponding public key (GxS1). It passes (GxS1) to the second party. It stores S1.

2) The second party generates a private key (S2) and a corresponding public key (GxS2). It stores S2.

3) The public key you use is the sum of the two public keys (GxS1 + GxS2). For OpenSSL, EC_POINT_add does this.

4) When you need the private key, you use (S1+S2) modulo the order.

This works because Gx(S1+S2) = GxS1 + GxS2. Neither party alone can get the needed private key.

Update: Actually, now that I think about it, it might work. But the way I mentioned above is simpler.

You don't actually do the ECC multiplication yourself - but you'll notice you call on the library to do it.  Look at whatever line of code takes a private key and turns it to a public key.  Chances are you're calling a "multiply" function out of a library, and you're passing it a constant called G (which came from the same library).

All you do is replace G with something else.  That "something else" is a public key.  G is the same "type" of data as a public key... in fact, the constant G is nothing more than the public key you would get if you used the number "1" (0x00000000000000000000000000000001) as a private key.

I am not sure what you mean by never having done "scalar multiplication" - this is normal multiplication - see, 5*10=50...that's scalar multiplication.  To combine two private keys you just do normal multiplication and division (using a bignum of course, to account for the fact that these numbers will be too big to fit in an int or float or whatever).

I think I see what you're getting at, and your assumption that I have a fair grasp on ECC is definitely correct, I'm just not entirely sure how to actually implement that functionality in real code. Practically everything ECC-related I've dealt with thus far has been happily encapsulated in simple little libraries - I've never actually had to do the scalar multiplication myself. Perhaps some day when I have the time to do serious digging, I can implement this, but I'll be honest enough to say that I don't have the skillset to start on it just yet.

Nope, just exploiting properties of ECC math to create a single key that both sides can agree on, but neither side knows the public key to, unless it has both private keys.

Basically how it works: you are probably aware that to create a public key from a private key, you multiply a number (the private key) by a constant G (which is an ECC point).  This step remains unchanged for the first party.

The first party sends that public key to the second party.  The second party also creates a private key, but instead of multiplying it by G, he multiplies it by the public key received from the first party.  The result is a new composite public key for which neither side knows the private key.

The math works two ways: if second party sends the public key to first party, who uses it in place of G, they will yield the same composite public key.

I believe (someone correct me if I'm wrong), the way to get the private key that corresponds to the composite public key, is to take the two private keys (which are integers), multiply them together, and mod them by some very large constant.  The result (another integer) is the composite private key.

Are you talking about multi-key or multi-signature transactions? I don't know enough about that particular functionality to implement it, even on the PC side, but I can confirm that adding sharing capability to some or all of the information on that screen is on my to-do list. I just wanted to put this in the public's hand ASAP, it'll be refined significantly in the future.

Very awesome...

Where to take this next: a two-factor savings wallet generator for average folks - you're already pretty much there!

How that would work:

1. User chooses passphrase in your app.  It generates a keypair just like your screenshot shows.  You add a quick function to send the pubkey to an e-mail address so they can get it on their computer.
2. They do the same thing on their computer, possibly with a web-based application.  They choose a second passphrase and provide the pubkey created in step 1.  The web-based application produces a Bitcoin address, which is associated with two passphrases.  The two pubkeys, of course, are merged by way of ECC multiplication.
3. Ideally the user will want some way to confirm that the produced address was legit. (An idea for how that might work follows)

The user can have a high level of confidence that the Bitcoin address they just created is secure from hackers and malware, and can be recovered simply by providing both passphrases.  A successful attack would require interception of the passphrase/privkey from both devices, which is pretty damn difficult!

User validation that the address creation was legit:
1. The website and phone app could accept the second passphrase to demonstrate its ability to come up with the same Bitcoin address, and then warn the user that they should not use either passphrase for any real money, since the goal is to never let any one machine know both passwords until it's time to spend.