[ANNOUNCE] Casascius-compatible address tool for Android.

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

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

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.

[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

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.

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

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

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

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.

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

To edit this into the code and update on GitHub? Minutes. To export and sign new APKs, upload them to Google and wait for those changes to be pushed via updates, that's up to Google but I can tell you it usually takes an hour + for those changes to show up.

[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

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.

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

To edit this into the code and update on GitHub? Minutes. To export and sign new APKs, upload them to Google and wait for those changes to be pushed via updates, that's up to Google but I can tell you it usually takes an hour + for those changes to show up.

Got it, bitcoin sent so you don't get to think i'm jerking around. Thanks

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

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

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.

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

To edit this into the code and update on GitHub? Minutes. To export and sign new APKs, upload them to Google and wait for those changes to be pushed via updates, that's up to Google but I can tell you it usually takes an hour + for those changes to show up.

Got it, bitcoin sent so you don't get to think i'm jerking around. Thanks

Tips are always appreciated. Updates have been pushed to both GitHub and Google Play with these changes. No guarantees on how long it'll take for the changes to show up in the latter, but the new code is live on GitHub now. Screenshot in first post has been updated to reflect the change.

QR codes will have to wait until tomorrow 

[JoelKatz]

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.

Do you have a link? Because I have a proof that anything that breaks this algorithm would be a general break of ECDSA. Obviously, if there is such a vulnerability, the proof must be incorrect and I'd love to figure out where it's invalid.

Here's the proof:

Call the honest party's private key H. All the honest party reveals is GxH.

Call the dishonest party's private key D.

The public key of the combined key is GxD + GxH. The private key of the combined key is D+H.

To break the private key, the dishonest party needs D+H.

If the dishonest party can calculate D+H, then he can calculated H by subtraction, since he chose D.

Thus, the dishonest party can calculate H, given only GxH.

Thus the dishonest party has broken ECDSA entirely.

Maybe the vulnerability involves the equivalent of an infinity point? Doesn't multiplication have precisely the same problem with zero?

[casascius]

Honest party chooses key H and gives GxH

Dishonest party should choose key D and give GxD

But instead he gives GxD-GxH

Honest party calculates the sum key by adding GxH to it and sends the funds

GxD-GxH+GxH = GxD

Dishonest party steals them with private key D

This scam is rendered impossible with multiplication as there exists no way for dishonest party to calculate GxD "/" GxH

A telltale sign is dishonest party will never know private key for the pubkey he calculated and gave.  He will not, for example, be able to sign a message with the pubkey he gave, when doing this scam, when otherwise he would.

[paraipan]

Thanks enmaku, you rock dude, now i'm able to "whisper" the bitcoins to anyone, by using words  

Casascius keep up the good work man. Have to say I was running around your program for quite some time without really knowing how to use it, but it was there thanks to you.

[enmaku]

Thanks enmaku, you rock dude, now i'm able to "whisper" the bitcoins to anyone, by using words  

Casascius keep up the good work man. Have to say I was running around your program for quite some time without really knowing how to use it, but it was there thanks to you.

Well, technically you could do that before, I just made it a bit more portable.

Thanks, though, this has been my first Android project in quite a long time. I've been so busy coding for work that it's been ages since I just wrote something because I felt like it. Here's hoping I don't wait that long to code for my own purposes ever again!

[JoelKatz]

Honest party chooses key H and gives GxH

Dishonest party should choose key D and give GxD

But instead he gives GxD-GxH

Wow! I didn't mention that the two initial messages in this protocol must be signed. That was really careless of me. Had someone implemented this without that, they would have been vulnerable to precisely this attack!

With the messages signed, he can't give GxD-GxH, since he doesn't know the corresponding private key. His attempt to sign the message giving it would fail. These messages are analogous to certificate requests and must be signed for the same reason.

Nice catch.

[casascius]

Honest party chooses key H and gives GxH

Dishonest party should choose key D and give GxD

But instead he gives GxD-GxH

Wow! I didn't mention that the two initial messages in this protocol must be signed. That was really careless of me. Had someone implemented this without that, they would have been vulnerable to precisely this attack!

With the messages signed, he can't give GxD-GxH, since he doesn't know the corresponding private key. His attempt to sign the message giving it would fail. These messages are analogous to certificate requests and must be signed for the same reason.

Nice catch.

By doing that you have doubled the payload that must be exchanged: now you must exchange a pubkey and a signature.  And must validate the signature, etc.

Doing ECC multiplication makes that all unnecessary.  It isn't that much more complicated, you're just calling a different operation in the same library.

The vulnerability wasn't my catch, I just parroted it from another thread when someone else explained it to me (I made the same proposal you did once upon a time).

[enmaku]

In all seriousness, though, if someone could take a glance over my code I'm having issues with zxing's QR codes.For some reason it generates these nice aesthetically pleasing QR codes for all the Base58 values - they're large enough to be scannable, they render roughly the same size as the textboxes, it's nice. Then for the hex value it produces what looks like a 30x30 QR code surrounded by a mile of whitespace in its 80x80 box...

[cbeast]

So you have an offline Brain Wallet Android device. Cool cool cool! Now how do we get the private key in text or QR to a paper backup without something going online? Is it possible to photocopy the LED display? Maybe use a camera or camcorder, or Polaroid? I'm sure I'm overlooking something.

[casascius]

So you have an offline Brain Wallet Android device. Cool cool cool! Now how do we get the private key in text or QR to a paper backup without something going online? Is it possible to photocopy the LED display? Maybe use a camera or camcorder, or Polaroid? I'm sure I'm overlooking something.

Isn't that what you don't want to do?  The thing you want to backup is the passphrase... the private key can always be recreated from it.  It is just plain old sha256.  What I figure you'd want to easily export is the bitcoin address / pubkey.

[enmaku]

After I got home and tested I realized that the tiny QR codes weren't scannable if you have a device with a very small screen (like my old HTC Eris that I'm using for exactly this purpose).

I've made the tiny QR codes clickable and they pull up a nice large full-screen QR code.

[vuce]

Honest party chooses key H and gives GxH

Dishonest party should choose key D and give GxD

But instead he gives GxD-GxH

Wow! I didn't mention that the two initial messages in this protocol must be signed. That was really careless of me. Had someone implemented this without that, they would have been vulnerable to precisely this attack!

With the messages signed, he can't give GxD-GxH, since he doesn't know the corresponding private key. His attempt to sign the message giving it would fail. These messages are analogous to certificate requests and must be signed for the same reason.

Nice catch.

By doing that you have doubled the payload that must be exchanged: now you must exchange a pubkey and a signature.  And must validate the signature, etc.

Doing ECC multiplication makes that all unnecessary.  It isn't that much more complicated, you're just calling a different operation in the same library.

The vulnerability wasn't my catch, I just parroted it from another thread when someone else explained it to me (I made the same proposal you did once upon a time).

Can you explain how this would go, I'm a bit confused. Getting g*a from one and g*b from the other party you can't multiply those as EC aren't a ring. (note that g is an EC point and a, b are integers)

edit: nevermind, missed your post from earlier.

One party chooses b, calculates g*b and sends that to the other party, which chooses a and sends g*a back. Both parties can calculate the public key (g*a)*b = (g*b)*a, the secret key is a*b. Is this a correct sum-up? (a, b are integers, g is an EC point)

This would basically be an EC version of Diffie-Hellman key exchange.

[JoelKatz]

One party chooses b, calculates g*b and sends that to the other party, which chooses a and sends g*a back. Both parties can calculate the public key (g*a)*b = (g*b)*a, the secret key is a*b. Is this a correct sum-up? (a, b are integers, g is an EC point)

Yes. You just have to watch out for the equivalents of 0, 1, and infinity if the two parties don't trust each other. There are no caveats if the two parties interests are aligned in securing the combined key.

[enmaku]

And after a long battle with onActivityResults not wanting to fire correctly, I've now added QR scanning capabilities to the "Passphrase" field, so you can scan in SHACodes from coins, bitbills, paper backups, tattoos, etc.

[westkybitcoins]

Nice.

[enmaku]

Nice.

Glad you like it! Now if I can just get whoever maintains the blockchain.info app to add QR->WIF import functionality (MtGox's app already has it, but I'm a blockchain.info fan) I'd have a completely functional system without any compromises