Can you consider making one app (or two separate apps) that replicate the features of bitaddress.org and brainwallet.org.
I'm not familiar with android development, but all you need to is package the github html and javascript files and the app is just a no permissions no internet access browser. You start the app, choose brainwallet or bitaddress. And voila, an offline version!
Topic: [ANNOUNCE] Casascius-compatible address tool for Android. (Read 4283 times)
Some suggestions/improvements for security:
- On the newer androids, the screenshot of the last state of the application is saved when switching programs.
Unfortunately, there might be no way to fix this when a user switches apps. Providing an exit button would be an option for those that utilize it.
- When scanning the public key, a rogue QR app scanning app (or a third party person) can see the brainwallet passphrase.
Suggestion to display the QR code with a full screen white background. Additionally, bitaddress.org has a hide/show password for the brainwallet, can add a checkbox to show typed passphrases as ********.
-Lock the screen orientation upon startup, or do not allow a change in screen orientation to exit the QR code on fullscreen. Again, a rogue QR scanning app, trojan with webcam access, or third party human will see the brainwallet passphrase and privatekey.
- On the newer androids, the screenshot of the last state of the application is saved when switching programs.
Unfortunately, there might be no way to fix this when a user switches apps. Providing an exit button would be an option for those that utilize it.
- When scanning the public key, a rogue QR app scanning app (or a third party person) can see the brainwallet passphrase.
Suggestion to display the QR code with a full screen white background. Additionally, bitaddress.org has a hide/show password for the brainwallet, can add a checkbox to show typed passphrases as ********.
-Lock the screen orientation upon startup, or do not allow a change in screen orientation to exit the QR code on fullscreen. Again, a rogue QR scanning app, trojan with webcam access, or third party human will see the brainwallet passphrase and privatekey.
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
Nice.
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.
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.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!Dishonest party should choose key D and give GxD
But instead he gives GxD-GxH
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.
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.
I've made the tiny QR codes clickable and they pull up a nice large full-screen QR code.
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.
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.
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...
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!Dishonest party should choose key D and give GxD
But instead he gives GxD-GxH
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).
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!Dishonest party should choose key D and give GxD
But instead he gives GxD-GxH
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.
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.
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!
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.
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.
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.
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.
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?
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
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
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.
Jump to: