[ANN] bitaddress.org Safe JavaScript Bitcoin address/private key

[pointbiz]

Hum... It doesn't work on my iPhone. Maybe because I can't move my mouse around? It hangs on "Generating Bitcoin Address...".

Anyway, a cellphone probably isn't the best place to use this.

A cellphone might be a good place to use this for a disposable address if someone wants to pay you and you don't have a bitcoin wallet handy.

I tested on a physical iPhone 3G Safari 4 and it doesn't work. I tested on Safari 3.2.3 for Windows and it works.
It appears that the Mobile Safari doesn't even support try/catch properly so there is little chance I can get this thing working on an iPhone.

Do you have Safari Mobile 4 or 5 ?

[1714601768]

1714601768

[1714601768]

1714601768

[1714601768]

1714601768

[casascius]

On a cell phone, how would you use such a thing?

On an iPhone you can take a screenshot by pressing both hardware buttons... do you mean that?  If so, that's an unusual way to do it, though it would work.  Otherwise, the private key will disappear as soon as you touch the window and the funds will be gone.

What part of the code necessitates a try/catch?

[nmat]

A cellphone might be a good place to use this for a disposable address if someone wants to pay you and you don't have a bitcoin wallet handy.

I tested on a physical iPhone 3G Safari 4 and it doesn't work. I tested on Safari 3.2.3 for Windows and it works.
It appears that the Mobile Safari doesn't even support try/catch properly so there is little chance I can get this thing working on an iPhone.

Do you have Safari Mobile 4 or 5 ?

I didn't thought of that. Interesting idea.

It's version 5. I enabled debug console and it shows an error after a while:

JavaScript Error on Line 1334
JavaScript execution exceeded timeout

I'm pretty sure it worked before you introduced the mouse thing.

[pointbiz]

Casascius, yes, I was thinking of the iPhone screenshot capability.

nmat, Debug Console huh... never noticed that option before. I confirm I see the timeout error, that would explain why I thought the try/catch wasn't working. I put a try/catch around generating the bitcoin address. It appears things are timing out in the "am3" function. I did notice in Safari 3.2.3 for Windows generating was painfully slow so I'd assume the iPhone Safari is processing the JavaScript at a snail's pace and timing out.

The mouse thing would cause trouble on an iPhone but I implemented a timeout which forces the bitcoin address generation after a few seconds and I confirmed that code it being called, the private key gets generated but things timeout when trying to create the public key. I checked on the older versions and they all timeout on Safari Mobile 4.

[casascius]

I am able to generate addresses on my iPhone 4... it is a bit slow but not unreasonable.  Couple of seconds.

[Jan]

At the moment I'm not convinced Deterministic Wallets are the way to go. People think alike and therefore the algorithms and patterns used to make Deterministic Wallets can be gamed en mass.

Consider these two possible wallet decisions:
1) using a 5-character password to create a Deterministic Wallet using some tool.
2) create a truly random private key and copy/paste it into a text file in an encrypted true crypt drive, that is protected with a 5-character password, that you back up in several locations online and offline.

In scenario #1 someone can turn their GPU farm to silently create a bunch of Deterministic Wallets and check them against the blockchain. Only 1 person has to have an easy password for this attack to work and it's more likely to be a profitable attack.

In scenario #2 someone has to personally hack you then make childs play of your password. Much less likely to happen and more expensive for an attacker. Your 5-character password is much safer on your computer or on dropbox then in the blockchain for anyone to brute force. Maybe I could enforce a minimum password size and minimum complexity.

All that being said thank you for the suggestion, I see there will probably be demand for this type of feature. It's definitely a complimentary feature that would make sense on bitaddress so I'll consider it in the future.

You should always use a salt when generating a deterministic wallet. The salt should be globally unique and easy to remember. An email address has those properties, and makes a rainbow attack impractical. This wiki discusses how it is done for the BCCAPI: http://code.google.com/p/bccapi/wiki/SecurityAndDeterministicWallets
The BCCAPI is opensource and available here: http://code.google.com/p/bccapi/

[nmat]

nmat, Debug Console huh... never noticed that option before. I confirm I see the timeout error, that would explain why I thought the try/catch wasn't working. I put a try/catch around generating the bitcoin address. It appears things are timing out in the "am3" function. I did notice in Safari 3.2.3 for Windows generating was painfully slow so I'd assume the iPhone Safari is processing the JavaScript at a snail's pace and timing out.

The mouse thing would cause trouble on an iPhone but I implemented a timeout which forces the bitcoin address generation after a few seconds and I confirmed that code it being called, the private key gets generated but things timeout when trying to create the public key. I checked on the older versions and they all timeout on Safari Mobile 4.

Actually I am not using an iPhone. It's a 2G iPod Touch with iOS 4.2.1 (so yes, it is a slow device).

[casascius]

You should always use a salt when generating a deterministic wallet. The salt should be globally unique and easy to remember. An email address has those properties, and makes a rainbow attack impractical. This wiki discusses how it is done for the BCCAPI: http://code.google.com/p/bccapi/wiki/SecurityAndDeterministicWallets
The BCCAPI is opensource and available here: http://code.google.com/p/bccapi/

I am not sure this applies in this case.  Rainbow attacks help attackers take a large number of hashes and try to recover plaintext from as many as possible with the same effort.  In wallet generation, the hashes are used as private keys which the attacker has no access to (or else if he gets the private keys, his attack has already succeeded, there's no value in recovering the plaintext itself).  This advice is useful for someone operating a website and storing hashed passwords in a database, but I believe it has no application for wallet generation.

Although I agree that the linked wiki article discusses it and recommends the user enter a "salt"... what practical difference would there be between the user entering a "salt" into a separate field, versus simply appending some extra characters to their passphrase?  They will be concatenated anyway, so none from what I can tell.  Salt in most other contexts is not something chosen by a user, rather it is something added by an application outside the user's control.

[Stephen Gornick]

This is so close to having a low-tech Do-It-Yourself paper-based solution for merchants.

With this, the merchant pre-prints out a batch of these with the public-key only (and its QR Code) on paper (such as blank personal check paper stock)  (see below)
 http://www.amazon.com/VersaCheck-Refills-Personal-Wallet-Prestige/dp/B00134O78S

And then generated is the merchant's master (see below) to be kept secure which contains the public-key (& QR Code) and also the private key (& QR Code) for redeeming.

Then at the point of sale the cashier has a supply of these pre-printed "check" blanks with Bitcoin addresses (see below).

When the purchase occurs, the cashier fills in the amount and invoice # (or other identifier for matching to the point of sale transaction) and provides the check blank to the customer.  The customer, using a mobile, scans the QR code and sends the bitcoins.

The merchant's back-office already has the address registered with BitcoinNotify.com so when payment is made (on 0/unconfirmed) an email (or SMS) is received.
  - http://bitcoinnotify.com

The cashier places the check in the drawer as the customer has paid and proceeds with completing the sale.

After the shift, the merchant's bookkeeper matches up the checks from the drawer against the corresponding master which has the private key, scans the key and spends those funds to the merchant's master wallet / consolidation address.  The "master" strip can then be stapled to the check and archived for records storage without having to further worry about securing the private key.

This could work.

Here's what I picture a batch of three checks looking like:  [Edit: obviously, each of the three would have a unique bitcoin address code, but being lazy, I just did a copy and paste using the same code for all three]


And the merchant's masters corresponding to the checks:

[pointbiz]

Actually I am not using an iPhone. It's a 2G iPod Touch with iOS 4.2.1 (so yes, it is a slow device).

I'm glad Casascius can generate on his iPhone4. Unfortunately for my device and yours we are pretty much out of luck.

There is a technique to use setTimeout to split up the JavaScript work into batches so it doesn't trigger a browser timeout (for desktop browsers usually you get a popup asking if you want to stop the script or wait). This technique is useful when you can do bulk processing but it's not wise to implement this technique to facilitate 1 address generation because the execution path and variable scopes change when you call setTimeout.
It's mentioned here in the top answer:
http://stackoverflow.com/questions/4402012/avoiding-timeouts-on-iphone

[pointbiz]

Stephen Gornick, very interesting idea. Thank you for describing the use-case so well.

I'm going to put some tabs on the user interface to accommodate designs for different use-cases.

The first two tabs will likely be:
1) Single Wallet: what exists now on the site. Use-case: Easy wallet... introduction for new users. Disposable wallet/Instant wallet.
2) Bulk Wallet: a way to generate a CSV list of addresses. Use-case: bulk generation for use with BitcoinNotify.com

Possible other tabs include:
Multi Wallet: like Single Wallet but with 5 or 6 to fill a whole page.
Merchant Wallet: Checks and Masters as described by Stephen Gornick.

[casascius]

Actually I am not using an iPhone. It's a 2G iPod Touch with iOS 4.2.1 (so yes, it is a slow device).

I'm glad Casascius can generate on his iPhone4. Unfortunately for my device and yours we are pretty much out of luck.

There is a technique to use setTimeout to split up the JavaScript work into batches so it doesn't trigger a browser timeout (for desktop browsers usually you get a popup asking if you want to stop the script or wait). This technique is useful when you can do bulk processing but it's not wise to implement this technique to facilitate 1 address generation because the execution path and variable scopes change when you call setTimeout.
It's mentioned here in the top answer:
http://stackoverflow.com/questions/4402012/avoiding-timeouts-on-iphone

I think the part of the code that, if divided, would yield the maximum sliceability of the workload, is the function ec.PointFp.prototype.multiply.  It contains a loop that repeatedly calls an add and a twice function.  I would be willing to bet that if you refactored this code so that it did 1 iteration of this loop per time slice, you could get each of the time slices small enough to run on slower devices.

This code gets reached in the part where the private key is being turned into a public key.

So if you were to timeslice it out, here's how it might work.  Click the New Address button, and you generate the private key and then you globalize all the variables maintained by the slow multiply function  (e, h, neg, R, i).  Each time slice, you do one iteration of its loop.  On the timeslice where the looping condition is no longer met, you have the return value R, which you feed into Bitcoin.Address(Bitcoin.Util.sha256ripe160(R)) and display everything.  Ungrey the button.  Voila

FYI a large amount of this code is unreferenced and unneeded.  There's references to many unneeded curves (the only one needed is secp256k1) and there are numerous elliptic curve functions that are not needed (the only one I believe is needed is multiply plus its dependencies).  All of the EC methods ending in "2D" can go as well, without impact to functionality.

[BkkCoins]

Wouldn't it be really handy if you could broadcast a transaction with your page too?

I'm just thinking it's the only part missing to go full circle. We can create an address+key here. We can receive payments to it since we don't need a client running for that.

Rather than importing the key into a client and sending coins couldn't you have a small form where you enter an address and amount, paste your key and it will create the signed transaction.

It could either generate a raw signed transaction text that you can copy and import into a client (so you don't need to expose the key), or if connected it could inject the transaction into the network. I'm not sure how much code that part would require or whether JS can handle it, but offhand it seems feasible. Or maybe it needs a server to inject the raw trx data? If there is change then either it would have to return it to the same address or you give it another address to send to.

With that capability I think you would have a fully functional paper wallet system.

[casascius]

It could either generate a raw signed transaction text that you can copy and import into a client (so you don't need to expose the key), or if connected it could inject the transaction into the network. I'm not sure how much code that part would require or whether JS can handle it, but offhand it seems feasible. Or maybe it needs a server to inject the raw trx data? If there is change then either it would have to return it to the same address or you give it another address to send to.

This would work, the only thing you would need is a way to know which available transactions were "out there" on the block chain to be spent.  Some sort of webservice would need to answer that, or that would have to be provided somehow through a sort of ugly copy-n-paste of base64 data or something.

If that webservice took ajax calls, and also took ajax calls asking it to drop transactions on the network, then YES a fully functional paper wallet bitcoin client could be implemented in javascript alone.

[Jan]

I am not sure this applies in this case.  Rainbow attacks help attackers take a large number of hashes and try to recover plaintext from as many as possible with the same effort.  In wallet generation, the hashes are used as private keys which the attacker has no access to (or else if he gets the private keys, his attack has already succeeded, there's no value in recovering the plaintext itself).  This advice is useful for someone operating a website and storing hashed passwords in a database, but I believe it has no application for wallet generation.

The attacker would not search for the private keys alone, he would calculate the private/public key and their corresponding address for all passwords up to a certain length (depending on his capacity), and store them in a table. Then he would scan incoming blocks for transactions that send coins to addresses that match his table. This allows him to harvest transaction outputs sending coins to addresses based on private keys that are generated on weak passwords. With one such table he can attack everyone using this scheme in parallel. 
If the key generation is based on both a password and something that is globally unique (such as an email address) the attacker will have to either calculate really really big tables (unfeasible) or make a targeted attack against a single user (provided that he knows his email address), yielding much less profit. 

Although I agree that the linked wiki article discusses it and recommends the user enter a "salt"... what practical difference would there be between the user entering a "salt" into a separate field, versus simply appending some extra characters to their passphrase?  They will be concatenated anyway, so none from what I can tell.  Salt in most other contexts is not something chosen by a user, rather it is something added by an application outside the user's control.

They aren't really concatenated, but seperate inputs to scrypt, which generates the seed used for deriving keys. The idea with the salt is that it is easy to remember, unique, and not a secret.  In practical terms it allows for stronger security without having the user remember/keep-secret a longer password. In a UI I would always keep this as two seperate fields, as this makes it easier for the user to understand that there is a secret component and a unique component of his wallet.

With deterministic wallets we cannot rely on a central component generating the salt. We need the salt to be the same whenever we wish to recreate the wallet.

[casascius]

The attacker would not search for the private keys alone, he would calculate the private/public key and their corresponding address for all passwords up to a certain length (depending on his capacity), and store them in a table. Then he would scan incoming blocks for transactions that send coins to addresses that match his table. This allows him to harvest transaction outputs sending coins to addresses based on private keys that are generated on weak passwords. With one such table he can attack everyone using this scheme in parallel.
If the key generation is based on both a password and something that is globally unique (such as an email address) the attacker will have to either calculate really really big tables (unfeasible) or make a targeted attack against a single user (provided that he knows his email address), yielding much less profit.

How much of a length do you have in mind?  The deterministic generators in existence now and that are proposed require passphrases with a minimum of 20-30 characters... this guy's table would have to have something like 10^37 entries, and he would need in excess of the world's capacity in hard drives to store it.  In addition, calculating ECDSA public/private keys is already a very slow operation, he would probably need in excess of his lifetime to produce just 10^20 keypairs and the GDP of a small country just to pay for the electricity, let alone 10^37.  This attack is effective against the fool who chooses "john's bitcoins" as his passphrase, but not against someone who uses a program that refuses to cooperate with a poor passphrase.

Although I agree that the linked wiki article discusses it and recommends the user enter a "salt"... what practical difference would there be between the user entering a "salt" into a separate field, versus simply appending some extra characters to their passphrase?  They will be concatenated anyway, so none from what I can tell.  Salt in most other contexts is not something chosen by a user, rather it is something added by an application outside the user's control.

They aren't really concatenated, but seperate inputs to scrypt, which generates the seed used for deriving keys. The idea with the salt is that it is easy to remember, unique, and not a secret.  In practical terms it allows for stronger security without having the user remember/keep-secret a longer password. In a UI I would always keep this as two seperate fields, as this makes it easier for the user to understand that there is a secret component and a unique component of his wallet.

With deterministic wallets we cannot rely on a central component generating the salt. We need the salt to be the same whenever we wish to recreate the wallet.

I still don't get it.  One component needs to be secret (but not unique) and the other needs to be unique (not secret)?

The whole point of a passphrase is to be both unique and secret.  If they're both, and they're long enough (entropy wise) that's all that's needed.

This completely makes sense in the context of using scrypt on, say, a website where there's a database, and per-user salt is stored separately from the user's brain.  If scrypt is the algorithm of choice, and the algorithm wants a salt, and the user has to remember it, why not just define the first n characters of the passphrase (or the hash of it) and call it the "salt", rather than burden the user with caring about the difference.  By demanding that the user understand "salt" to use a payment system, the size of the potential audience willing to use the payment system just gets quartered or worse.

[BurtW]

Love your program.  Sent you a small donation. 

Question:  do you have any idea why it is that when I print the paper copy of the key pair from IE the QR codes do not print but when I print from Safari the QR codes do print (other than Microsoft sucks)?

[casascius]

Love your program.  Sent you a small donation. 

Question:  do you have any idea why it is that when I print the paper copy of the key pair from IE the QR codes do not print but when I print from Safari the QR codes do print (other than Microsoft sucks)?

Yes, his source code acknowledges that problem.  On IE (just IE8?) the browser apparently does not support a "canvas object" which is necessary for the Javascript to render a printable image so he uses a hack that makes it work on screen but not in print.

[casascius]

I just discovered something that I hope will make it print.

My understanding is that the QR code on IE8 is formed by creating a table full of little cells and setting their background colors to white or black.

IE does not normally print the background color of table cells on printers.  But there is a checkbox in Page Setup that turns this on.  Check the box.  Try it again.

[pointbiz]

Love your program.  Sent you a small donation. 

Question:  do you have any idea why it is that when I print the paper copy of the key pair from IE the QR codes do not print but when I print from Safari the QR codes do print (other than Microsoft sucks)?

Thanks for the donation!

Regarding IE8 it is as Casascius has described. I figured if I could show the QR Code in IE8 then one day I'd figure out how to print it. Thankfully Casascius has found an immediate solution. I may try putting characters in each TD tag with a really small font but I don't think the quality of the QRCode would be as good as clicking that option in the "Page Setup" of the Print Preview screen in IE8.