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

[pointbiz]

v0.7
http://www.bitaddress.org/bitaddress.org-v0.7-SHA1-34e344a0d229dc10c8f5c99ed6b6298e6fc5e39f.html
 -Added Bulk Wallet tab. Now you can generate CSV lists of addresses!

Use-case: Generate lists of wallets you will copy/paste to an encrypted location. Could be very useful for merchants in conjunction with a service like bitcoinnotify.com

Another use is a multi page wallet. With Chrome you can drag the text area down and print as many pages as you'd like.

Example:

[1715168751]

1715168751

[1715168751]

1715168751

[1715168751]

1715168751

[BkkCoins]

That's excellent and I could see that being useful.

(Maybe you could add

.menu .tab { cursor:pointer }

to the css so the tabs get a finger pointer instead of a caret... just a bit nicer.
I tested this here with FireBug)

[casascius]

Sweet CSV option!  Suggestion, put doublequotes around strings so applications interpret them as text rather than trying to parse them as numbers (and choking on the letters). The index should remain unquoted.

[pointbiz]

v0.8
http://www.bitaddress.org/bitaddress.org-v0.8-SHA1-47b989b8a33407df14d21dbd00fad653e0161d6c.html
 -Css update to tabs
 -Added double quotes around CSV bitcoin address and private key output

[nmat]

Great work 

[Jan]

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.  

The post I referenced originally mentioned 5 characters, which makes a rainbow attack trivial:

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

Creating a keypair is not computationally hard and can be implemented effectively and cheaply in hardware.
For long passwords the attack can be turned around by making a table of all addresses in use and continously guessing at passwords.

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.

We want normal people to use Bitcoin. Asking the average Joe to memorize a complex 30 character password is error prone and will surely result in many lost wallets. The whole point of the salt and scrypt is that you can do with a shorter password that is easier to remember.

We make a rainbow attack unfeasible by using a unique salt that is easy to remember instead of a very long password.
We can make a direct brute force attack against a single wallet (where the salt is known) unfeasible by making each brute force attempt computationally hard. Scrypt achieves this both for software and hardware implementations. So basically we can reduce the password length by requireing the user's software to spend CPU during initialization.

If we make sure that brute forcing the private key from password is computationally as hard as brute forcing the private key from a public key we have something that is as safe as the Bitcoin system.

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.

The UI will be simple. "Enter your password" "Enter your email address". The CPU demanding calculation is only done when you wish to create/re-create your wallet.

[casascius]

The UI will be simple. "Enter your password" "Enter your email address". The CPU demanding calculation is only done when you wish to create/re-create your wallet.

And I assume e-mail address is used as the salt?  I would probably agree that would be joe-friendly and work as a salt.

The post I referenced originally mentioned 5 characters, which makes a rainbow attack trivial:

I am not sure he seriously intended to mean that people should choose 5 character passwords.

Creating a keypair is not computationally hard and can be implemented effectively and cheaply in hardware.

I'm not saying it's hard, I'm just saying it's very slow compared to (as an example) hashing.  It won't stop the attack, but it will slow it enough to make a difference.

For long passwords the attack can be turned around by making a table of all addresses in use and continously guessing at passwords.

For appropriately long passwords, that attack is unlikely to yield any results within the span of the attacker's lifetime.

We want normal people to use Bitcoin. Asking the average Joe to memorize a complex 30 character password is error prone and will surely result in many lost wallets. The whole point of the salt and scrypt is that you can do with a shorter password that is easier to remember.

A 30 character password need not be complex to be secure.  "Stinklers in the pie--with guymonds" would be just as memorable as "Fxh00w3e" without being short.  I would think that a password like this should be written down and kept in a safe place where joe's next of kin will find it if necessary.  Since it won't be used regularly, joe won't have the benefit of needing to recall it daily - which would help him remember it - like he would with other passwords.

I will definitely agree with you that the benefit of having a computationally expensive algorithm like scrypt is clearly beneficial, and that having the user provide his e-mail address (or any other non-secret datum he is unlikely to forget or confuse) as salt is an excellent user-friendly idea.

[pointbiz]

The post I referenced originally mentioned 5 characters, which makes a rainbow attack trivial:

I am not sure he seriously intended to mean that people should choose 5 character passwords.

I mentioned 5 characters to highlight the point that if something is weakly encrypted it is much safer on your computer then publicly brute force-able in the block chain.

[pointbiz]

SSL now available:
https://www.bitaddress.org/bitaddress.org-v0.8-SHA1-47b989b8a33407df14d21dbd00fad653e0161d6c.html

Now you can browse via HTTPS this is to mitigate a man-in-the-middle attack.


I moved my hosting to a place where I can host it and pay for the SSL certificate with Bitcoins. Thanks again to those who have donated. Your BTC went to help with the hosting costs!!

[casascius]

I am planning on donating another 5 BTC if you can modify it so you can enter the number of QR-code-pairs on a page just like on the CSV, rather than having just one.  And also, are you releasing this as open source?  If so, can you add a licensing header in the comments?

[racerguy]

I think that just means pywallet can't do transactions, but can still import/export addresses just fine.

[pointbiz]

I am planning on donating another 5 BTC if you can modify it so you can enter the number of QR-code-pairs on a page just like on the CSV, rather than having just one.  And also, are you releasing this as open source?  If so, can you add a licensing header in the comments?

I will take you up on that offer... I will call that feature 'Multi Wallet' or 'Paper Wallet' and it will be the next item on my TODO list.

Should the user enter the: 
1) number of QR-code-pairs ?  OR
2) number of QR-code-pairs per page and number of pages?  OR
3) number of pages ?

It looks like roughly 5 or 6 QR-code-pairs would fit on one page assuming they are the same height as used in the Single Wallet.

You mentioned previously about leaving space to write what each wallet is used for. In the Single Wallet design there is one line of space between the btc address and the private key. Lets call the QR-code-pair a 'box'. I thought it's more appropriate to write inside each box but let me know if you think the space between the btc address and private key should be reduced in favor of vertical space between the multiple 'boxes'.

Regarding, open sourcing the code... I had not really thought about it, for now I'll say no but I'll reconsider in the future if there's a compelling reason. With that being said, the most useful and reusable parts of the code ARE open source. I will provide a comment at the top of the page to help clarify the licensing situation.

Here is a summary of the JavaScript functions used in the code that have a redistributable license:

Code:

JavaScript function			License
-------------------			--------------
Array.prototype.map			Public Domain
window.Crypto				BSD License
window.SecureRandom			BSD License
window.EllipticCurve			BSD License
window.BigInteger			BSD License
window.QRCode				MIT License

            
I don't know what the license information is for the window.Bitcoin function as that information is not available on github for bitcoinjs-lib. The only thing modified in the window.Bitcoin function is the addition of the sipa private key wallet import format which I have offered to Stephan Thomas to add into the bitcoinjs-lib.

[casascius]

I would suggest you just let someone set the number of codes and not worry about pagination.  lots of browsers, lots of page sizes, lots of ways to cause unintended side effects, it is well within right to leave page setup to the user.

Yes space to write is good. Just the format you have now is great. Six to a page is plenty.  I have already used your site to make a QR paperwallet I am actively using. (got a USB QR code scanner and am enjoying using it.)

[Stephen Gornick]

There is a forum post reporting a problem sending from a v0.3.2x client to "any address generated by BitcoinAddress".

I don't have v0.3.2x anymore to test.  Would someone be able to provide a response:
 - http://bitcointalk.org/index.php?topic=46355.msg553309#msg553309

[Stephen Gornick]

I don't have v0.3.2x anymore to test.  Would someone be able to provide a response:

Hm, looks like actually the problem being reported is with v0.3.19.  Would be a problem for BitAddress even if it is that older version.  Can anyone else confirm either way? 
 - http://bitcointalk.org/index.php?topic=46355.msg553631#msg553631

[casascius]

I doubt that the problem is with BitAddress.  I see it as more likely that some junk ended up on the clipboard (like a trailing space) that the old Bitcoin client didn't trim out.

I verified tons (10,000+) of addresses generated by BitAddress for validity independently using a Windows-based script I wrote.  Not once did BitAddress issue a non-well-formed Bitcoin address, even in the older versions afflicted by bugs affecting the private key.

[pointbiz]

BlockExplorer shows that it's a valid Bitcoin Address:
http://blockexplorer.com/q/checkaddress/1PyrrD1EnHminnFPipPGyve4HiVyJPKmGy

I tried installing v0.3.19 to test but I could not get that version to run on Windows 7.

[trentzb]

Nice work!

[pointbiz]

Cusipzzz confirmed he could sent 0.02 BTC to the address provided by jago25_98 in the other thread.
https://bitcointalk.org/index.php?topic=46355.msg553869#msg553869

So I consider the case closed. Looks like the issue the guy had in the other thread was that he could not send 0.0001 BTC from the v0.3.19 client and that is because the transaction fee was 0.01 BTC in that version, and he tried to send an amount less than the transaction fee and the daemon gave him an incorrect error message. He didn't have issues with the v0.4.0 version because the transaction fee is now reduced to 0.0001.

[pointbiz]

v0.9
https://www.bitaddress.org/bitaddress.org-v0.9-SHA1-aa61ca480288e1bda00f1f042d60a057880a2321.html

-Added more entropy, all mouse movements in the window will add to the random seed pool.
-Added PaperWallet tab. You can now generate multiple QRCode pairs per page.