[ANNOUNCE] Casascius-compatible address tool for Android.

[enmaku]

So I've had this old Android phone laying around for ages and I kept thinking, what could I do with this? I decided one day that a simple app combined with airplane mode would make it an ideal offline brain-wallet, but no such utility seemed to exist. I finally got tired of waiting for someone else to get around to it and built it myself.

I introduce to you, the Android Bitcoin Address Tool:

 

It's pretty basic, but it does exactly what it was built for - it produces a Bitcoin address and associated private key from the an SHA256 hash of a passphrase. I also went to great lengths to ensure that the operations are bit-for-bit compatible with Casascius' already existing Bitcoin Address Utility as you can see from screenshot #2:



Same passphrase, same results.

It should be noted that this is very young code. I've done my best to trap for errors but it should be considered beta and just as with Casascius' utility, no warranty is implied. I also haven't implemented any code to validate Casascius-style SHACodes (Mini Privkey Format), so if you don't type your code correctly, that's on you.  

Want to support the project? Donations of BTC are accepted at the address in my signature, or there's a 99 cent donation version available in the marketplace.

Want to peek at the source and make sure I'm not some nasty trojan-planting H4XX0R waiting to steal your wallet? Go grab my code from the GitHub repo and poke through it yourself (or wait for / bribe someone else to do it). BitcoinJ et al carry their own licenses of course, but my own code (the stuff in the .java files as opposed to .jar) carries a "do whatever you want with it I really don't care" license.

Questions? Comments? Feature requests? Shoot me a reply or PM and I'll do what I can - or in the case of feature requests, feel free to fork it yourself if you know a little Java.

[1714822274]

1714822274

[1714822274]

1714822274

[1714822274]

1714822274

[1714822274]

1714822274

[enmaku]

Reserved for future updates.

[casascius]

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.

[enmaku]

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 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!

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.

[casascius]

Are you talking about multi-key transactions?

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.

[enmaku]

Are you talking about multi-key transactions?

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.

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.

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.

[casascius]

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.

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).

[JoelKatz]

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.

...

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.

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.

[enmaku]

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.

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).

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

Code:

    static {
        // All clients must agree on the curve to use by agreement. Bitcoin uses secp256k1.
        X9ECParameters params = SECNamedCurves.getByName("secp256k1");
        ecParams = new ECDomainParameters(params.getCurve(), params.getG(), params.getN(), params.getH());
        secureRandom = new SecureRandom();
    }

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.

[paraipan]

interesting...

[enmaku]

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.

...

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.

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.

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...

[imsaguy]

So I've had this old Android phone laying around for ages and I kept thinking, what could I do with this? I decided one day that a simple app combined with airplane mode would make it an ideal offline brain-wallet, but no such utility seemed to exist. I finally got tired of waiting for someone else to get around to it and built it myself.

I introduce to you, the Android Bitcoin Address Tool:



It's pretty basic, but it does exactly what it was built for - it produces a Bitcoin address and associated private key from the an SHA256 hash of a passphrase. I also went to great lengths to ensure that the operations are bit-for-bit compatible with Casascius' already existing Bitcoin Address Utility as you can see from screenshot #2:



Same passphrase, same results.

It should be noted that this is very young code. I've done my best to trap for errors but it should be considered beta and just as with Casascius' utility, no warranty is implied. I also haven't implemented any code to validate Casascius-style SHACodes (Mini Privkey Format), so if you don't type your code correctly, that's on you.  

Want to support the project? Donations of BTC are accepted at the address in my signature, or there's a 99 cent donation version available in the marketplace.

Want to peek at the source and make sure I'm not some nasty trojan-planting H4XX0R waiting to steal your wallet? Go grab my code from the GitHub repo and poke through it yourself (or wait for / bribe someone else to do it). BitcoinJ et al carry their own licenses of course, but my own code (the stuff in the .java files as opposed to .jar) carries a "do whatever you want with it I really don't care" license.

Questions? Comments? Feature requests? Shoot me a reply or PM and I'll do what I can - or in the case of feature requests, feel free to fork it yourself if you know a little Java.

Could you then present this address as a QR code so a live phone or other device could send coins to it?

[enmaku]

Could you then present this address as a QR code so a live phone or other device could send coins to it?

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

[imsaguy]

Could you then present this address as a QR code so a live phone or other device could send coins to it?

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

Pretty sweet!  Thanks for this.

[cbeast]

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!

[paraipan]

Could you then present this address as a QR code so a live phone or other device could send coins to it?

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

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

[imsaguy]

Could you then present this address as a QR code so a live phone or other device could send coins to it?

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

How can you copy the generated priv key or address ?

That could easily be a qr code as well.

[enmaku]

Could you then present this address as a QR code so a live phone or other device could send coins to it?

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

How can you copy the generated priv key or address ?

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.

[paraipan]

Could you then present this address as a QR code so a live phone or other device could send coins to it?

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

How can you copy the generated priv key or address ?

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.

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

[casascius]

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.

...

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.

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.

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.