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

[Stephen Gornick]

v2.1

I can verify that the BitAddress.org website has been updated and returns the same HTML from the commit with the description v2.1 (d34b4f7f9a219293238f93507617586f5ba4db17) in github:
 - https://github.com/pointbiz/bitaddress.org


To confirm this I first check the sha1sum hash of the html returned by a request to http://bitaddress.org:

$ wget --quiet -O - http://bitaddress.org|sha1sum
af431934553aeef3e042e796a31ee101cdabc496  -

$ GET -eSd bitaddress.org|grep -i "200 OK"
GET https://www.bitaddress.org/bitaddress.org-v2.1-SHA1-af431934553aeef3e042e796a31ee101cdabc496.html --> 200 OK


Then from my bitaddress.org repo:

$ git checkout master
$ git pull
$ git log --pretty=oneline|grep "v2.1"
d34b4f7f9a219293238f93507617586f5ba4db17 v2.1 Vanity Wallet add/multiply public/private keys. Code refactors.

$ git checkout d34b4f7f9a219293238f93507617586f5ba4db17
$ git rev-list --max-count=1 HEAD
d34b4f7f9a219293238f93507617586f5ba4db17

$ sha1sum bitaddress.org.html
af431934553aeef3e042e796a31ee101cdabc496  bitaddress.org.html

[phelix]

exactly. QR codes are readable the best when they are aligned to full pixel/dot sizes. e.g. 6 dots per module.

If your intent is to print a QR code, your best bet is to render it in a vector format (SVG, EPS, etc.) and let the printer scale it. The pixels will end up getting rendered as a grid of black and white squares, which can be scaled up/down to any size without losing quality.

My note generator script includes code that renders QR codes to EPS. Rendering to SVG isn't too different from that.

not really. at some point they will be squeezed into the print raster and potentially end up differently sized.

[pointbiz]

To generate a split key there is a new feature (v2.1) in the Vanity Wallet on bitaddress.org
It requires using two computers that are not compromised by the same attacker. For example using your computer at HOME and one at WORK.

Save the bitaddress.org HTML (get it from github) and check the SHA1 hash.

Open your saved bitaddress on your HOME computer and go to the Vanity Wallet tab. Click generate on Step 1. Print the page. We will call this key pair A (which consists of public key A and private key A). Copy and paste public key A into an email and send it to yourself at WORK.

Open your saved bitaddress on your WORK computer and go to the Vanity Wallet tab. Click generate on Step 1. Print the page. We will call this key pair B. Copy and paste public key B into an input box for Step 2. Then get public key A from the email you sent above and paste it into the other input box for Step 2.

Select Add and click Calculate Vanity Wallet. You will now have a secure Bitcoin address for saving.

When you later go to combine the private keys on one computer to get your coins out of savings then spend the whole balance (aka sweep) and don't use that same address anymore for savings. Consider it compromised.

See this thread:
https://bitcointalk.org/index.php?topic=114074.0

[TTBit]

I can't get something to work correctly using EC Multiplication. Might be a bug, or I am doing something wrong.

Key A:
Private: B1202A137E917536B3B4C5010C3FF5DDD4784917B3EEF21D3A3BF21B2E03310C
Public: 0429BF26C0AF7D31D608474CEBD49DA6E7C541B8FAD95404B897643476CE621CFD05E24F7AE8DE8 033AADE5857DB837E0B704A31FDDFE574F6ECA879643A0D3709

Key B:
Private: 7DE52819F1553C2BFEDE6A2628B6FDDF03C2A07EB21CF77ACA6C2C3D252E1FD9
Public: 04F04BF260DCCC46061B5868F60FE962C77B5379698658C98A93C3129F5F98938020F36EBBDE6F1 BEAF98E5BD0E425747E68B0F2FB7A2A59EDE93F43C0D78156FF

Multiply Public A * Private B
Address: 1HK25YbSJnfgBWGwA4uSZMnkpu6AXY17UB

Multiply Private A * Public B
Address: 1GvHY3ttLBc4yS9gNy8tJKxKQ5vBvBJ9Xa **Incorrect**

Multiply Private A * Private B
Address: 1HK25YbSJnfgBWGwA4uSZMnkpu6AXY17UB


Great utility, thank you PointBiz for the application!

[casascius]

I can't get something to work correctly using EC Multiplication. Might be a bug, or I am doing something wrong.

Key A:
Private: B1202A137E917536B3B4C5010C3FF5DDD4784917B3EEF21D3A3BF21B2E03310C
Public: 0429BF26C0AF7D31D608474CEBD49DA6E7C541B8FAD95404B897643476CE621CFD05E24F7AE8DE8 033AADE5857DB837E0B704A31FDDFE574F6ECA879643A0D3709

Key B:
Private: 7DE52819F1553C2BFEDE6A2628B6FDDF03C2A07EB21CF77ACA6C2C3D252E1FD9
Public: 04F04BF260DCCC46061B5868F60FE962C77B5379698658C98A93C3129F5F98938020F36EBBDE6F1 BEAF98E5BD0E425747E68B0F2FB7A2A59EDE93F43C0D78156FF

Multiply Public A * Private B
Address: 1HK25YbSJnfgBWGwA4uSZMnkpu6AXY17UB

Multiply Private A * Public B
Address: 1GvHY3ttLBc4yS9gNy8tJKxKQ5vBvBJ9Xa **Incorrect**

Multiply Private A * Private B
Address: 1HK25YbSJnfgBWGwA4uSZMnkpu6AXY17UB


Great utility, thank you PointBiz for the application!

I ran these numbers through my own utility for Windows and would guess it's probably a bug in the bitaddress application.  My Windows app provides the "correct" answer in all cases.

If I do Add instead of Multiply on these same numbers, BitAddress gives me output that matches my utility's output.

[pointbiz]

I can't get something to work correctly using EC Multiplication. Might be a bug, or I am doing something wrong.

Key A:
Private: B1202A137E917536B3B4C5010C3FF5DDD4784917B3EEF21D3A3BF21B2E03310C
Public: 0429BF26C0AF7D31D608474CEBD49DA6E7C541B8FAD95404B897643476CE621CFD05E24F7AE8DE8 033AADE5857DB837E0B704A31FDDFE574F6ECA879643A0D3709

Key B:
Private: 7DE52819F1553C2BFEDE6A2628B6FDDF03C2A07EB21CF77ACA6C2C3D252E1FD9
Public: 04F04BF260DCCC46061B5868F60FE962C77B5379698658C98A93C3129F5F98938020F36EBBDE6F1 BEAF98E5BD0E425747E68B0F2FB7A2A59EDE93F43C0D78156FF

Multiply Public A * Private B
Address: 1HK25YbSJnfgBWGwA4uSZMnkpu6AXY17UB

Multiply Private A * Public B
Address: 1GvHY3ttLBc4yS9gNy8tJKxKQ5vBvBJ9Xa **Incorrect**

Multiply Private A * Private B
Address: 1HK25YbSJnfgBWGwA4uSZMnkpu6AXY17UB


Great utility, thank you PointBiz for the application!

This is the fix to the critical bug above.

Code:

- var bigInt = new BigInteger(privKeyBytes);
+ var bigInt = BigInteger.fromByteArrayUnsigned(privKeyBytes);

Sorry about the bug and thanks for finding it so fast. I have added unit tests to the code base to help avoid these type of bugs. I have added a specific test that shows the bug is now fixed.

The fix is now live as part of v2.2:
https://www.bitaddress.org/bitaddress.org-v2.2-SHA1-d414530eea984e9ebdd40dc27af9078cd73dc3b3.html
 - critical bug fix to Vanity Wallet multiplication of a public key with a private key.
   Bug was due to incorrect construction of BigInteger object. Which results in the incorrect
   Bitcoin Address being displayed. Therefore, v2.1 has been taken offline.
 - new translations code and initial spanish translation. Thanks to dserrano5 for translating.

[Stephen Gornick]

The fix is now live as part of v2.2:
https://www.bitaddress.org/bitaddress.org-v2.2-SHA1-d414530eea984e9ebdd40dc27af9078cd73dc3b3.html

I can verify that the BitAddress.org website has been updated and returns the same HTML from the commit with the description v2.2 (685e977461ce00ab1a0925f193463727b4d28db0) in github:
 - https://github.com/pointbiz/bitaddress.org


To confirm this I first check the sha1sum hash of the html returned by a request to http://bitaddress.org:

$ wget --quiet -O - http://bitaddress.org|sha1sum
d414530eea984e9ebdd40dc27af9078cd73dc3b3  -

$ GET -eSd bitaddress.org|grep -i "200 OK"
GET https://www.bitaddress.org/bitaddress.org-v2.2-SHA1-d414530eea984e9ebdd40dc27af9078cd73dc3b3.html --> 200 OK


Then from my bitaddress.org repo:

$ git checkout master
$ git pull
$ git log --pretty=oneline|grep "v2.2"
685e977461ce00ab1a0925f193463727b4d28db0 v2.2 critical bug fix for Vanity Wallet multiplication of a public key with a private key

$ git checkout 685e977461ce00ab1a0925f193463727b4d28db0
$ git rev-list --max-count=1 HEAD
685e977461ce00ab1a0925f193463727b4d28db0

$ sha1sum bitaddress.org.html
d414530eea984e9ebdd40dc27af9078cd73dc3b3  bitaddress.org.html

[dooglus]

The fix is now live as part of v2.2:

I just saw the following message from v2.2:

Invalid input. Cannot multiple two public keys. Select 'Add' to add two public keys to get a bitcoin address.

Should that say "multiply" not "multiple"?

[salfter]

exactly. QR codes are readable the best when they are aligned to full pixel/dot sizes. e.g. 6 dots per module.

If your intent is to print a QR code, your best bet is to render it in a vector format (SVG, EPS, etc.) and let the printer scale it. The pixels will end up getting rendered as a grid of black and white squares, which can be scaled up/down to any size without losing quality.

My note generator script includes code that renders QR codes to EPS. Rendering to SVG isn't too different from that.

not really. at some point they will be squeezed into the print raster and potentially end up differently sized.

True, but the printer knows its capabilities and will render at an appropriate size.  If you're passing it a bitmap, you're stuck with either (1) sending a low-resolution bitmap that may not print with adequate quality or (2) sending a really high-resolution bitmap that most likely is overkill.  In either case, the printer will probably have to scale the image.

bitaddress.org uses the highest error-correction level (H) for its QR codes.  Private keys are thus rendered to a QR code with a 41x41 grid.  It renders each space in the grid as a 20x20 block, producing an 820x820 PNG that gets printed at approximately 1 1/16".  820/1.0625=about 771.76 dpi, which doesn't correspond to the native resolution of any printer I've heard of.  When printing paper wallets with the note artwork, scaling artifacts may be visible.  In testing with a Firefox nightly build on WinXP, printing to an HP LaserJet 1020, tops and bottoms of some elements of the QR codes have "rough" edges, most likely an artifact of a dithering algorithm somewhere in the rendering path.

There are no visible scaling artifacts in the notes generated by my script when the resulting PDF is printed from either PDF-Xchange Viewer or Adobe Reader.  (Can't say the same for the PDF viewer built into Firefox...it does an especially crappy job.  Considering the results produced above, it could be a rendering deficiency in Firefox.) My script renders QR codes to EPS and lays them out on the page with PostScript which is then converted to PDF by Ghostscript.

Just as a test, I thought I'd try combining the note image used by bitaddress.org with an SVG private-key QR code:

https://dl.dropbox.com/u/57535575/test.html

It renders on-screen and prints properly in Firefox for Linux.  On Windows, it renders properly in both Chrome and Firefox, but the QR code doesn't print in Firefox at all and prints at low resolution in Chrome.

As an aside, SVG QR codes can be generated with something like this (as was used in the preceding example):

Code:

qrencode -s 1 -l H -t EPS -o - 5KXNL2LtQwTQiNomaHryx2nCg4aGb3vz5qaNXa4zjyu336x2JrC | ./fix-qr-eps.awk | pstoedit - -f fig - 2>/dev/null | fig2dev -L svg >tmp.svg

This depends on qrencode, pstoedit, transfig, and an awk script, fix-qr-eps.awk:

Code:

#!/usr/bin/awk -f
$1 == "%%BoundingBox:" {print; w=$4-$2; h=$5-$3; x=$2; y=$3; next}
$1 == "%%EndComments" {print; print "gsave 3 3 scale 1 setgray "x" "y" moveto 0 "w" rlineto "h" 0 rlineto 0 -"w" rlineto -"h" 0 rlineto fill grestore"; next}
{print}

The purpose of the awk script is to add a white background to the image; it edits the EPS produced by qrencode before converting it to SVG.  What it would take to do this in JavaScript, I couldn't say.

[TheKoziTwo]

First of all, great work! I am considering to use this for long term storage. How many have reviewed the code as safe? The older bugs really freaks me out, I don't want to come back in 10 years when bitcoin is worth $10k/btc just to figure out my wallet doesn't work. Is version 2.2 really safe ?

[salfter]

More for shits and grins than for anything else (and because I just got a Galaxy Tab 2 7.0 for my birthday recently), I've forked bitaddress.org so I could feed it to PhoneGap Build (which requires an index.html file in your project).  The result is here:

http://dl.dropbox.com/u/57535575/bitaddress_org.apk

This download link provided by PhoneGap Build might also work:

http://s3.amazonaws.com/android.phonegap/slicehost-production/apps/226626/bitaddress_org-debug.apk

It's unsigned, so you might need to enable installing from unknown (?) sources. It works for me, but since it's my first build of an Android app (and since I have a whopping two days' experience with using Android), it may be less than optimal in some ways. I had tried doing an iOS build previously to get something similar for my iPhone and iPad, but that requires paying ~$100 to Apple for a build key.

[casascius]

First of all, great work! I am considering to use this for long term storage. How many have reviewed the code as safe? The older bugs really freaks me out, I don't want to come back in 10 years when bitcoin is worth $10k/btc just to figure out my wallet doesn't work. Is version 2.2 really safe ?

Let's pretend that 1 in 100 wallets is "bad" (which much resembles the 1 in 256 bug I found way back when).

If you print a batch of paper wallets, test a few, and then divide your BTC stash among many of them, then the risk of one being bad is actually quite tolerable.

That said, I've funded decent amounts onto Bitaddress.org paper wallets with **NO** heartburn whatsoever.  Back when I found the bug I found, it's because I thought just like you, and personally took it upon myself to go and test the output of a run of 10,000+ private keys generated by bitaddress (part of why it happens to support a CSV generation feature - I asked for it so I could test its output).  Now that I can confirm that huge batches of keys test 100% correct against a completely independent implementation of the same thing (my Windows generator written in C#), I have no heartburn using it for large amounts.  In fact, I got paid $10k worth of BTC in person by someone not too long ago, and had a bitaddress paper wallet in my pocket, since I carry a couple fresh paper wallets just for this reason.  I ripped it in half, gave him the bitcoin address part, and said "here, here's my payment address".  It worked just like it was supposed to.

You know what wouldn't be a bad idea?  If I wrote the same CSV function in my Windows utility.  Meanwhile, if both pointbiz and I added a function to each of our apps just to verify the output of the other.  This way it would be easy for others to repeat that same test.

[pointbiz]

You know what wouldn't be a bad idea?  If I wrote the same CSV function in my Windows utility.  Meanwhile, if both pointbiz and I added a function to each of our apps just to verify the output of the other.  This way it would be easy for others to repeat that same test.

The more testing the better. More eyes too! It's not good to proof read one's own essay.

I have setup some unit tests that will run when ?unittests=true I could expand the functionality so that a text area would appear for the user to paste a CSV in the same format as the Bulk Wallet tab and then verify the Bitcoin address for each private key in the CSV is correct. With the same functionality in your C# app it should add confidence to the correctness of the JavaScript implementation.

[pc]

I think at this point, the bitaddress.org calculations are correct and gives you the right address for a private key. I've used the "Wallet Details" tab a bunch to verify my offline generator that uses OpenSSL, and it works great.

My biggest concern about using it to make a paper wallet is one that I don't think is really knowable just by looking at the code unless you're a real crypto expert: Just how "random" is its generator? I don't know if JavaScript exposes the system's random source (and I don't know as I'd want it to), so are there enough ways to move the mouse and such however it's getting its entropy that the private key really does have the full 256 bits of randomness, or at least enough bits for most applications?

[TheKoziTwo]

First of all, great work! I am considering to use this for long term storage. How many have reviewed the code as safe? The older bugs really freaks me out, I don't want to come back in 10 years when bitcoin is worth $10k/btc just to figure out my wallet doesn't work. Is version 2.2 really safe ?

Let's pretend that 1 in 100 wallets is "bad" (which much resembles the 1 in 256 bug I found way back when).

If you print a batch of paper wallets, test a few, and then divide your BTC stash among many of them, then the risk of one being bad is actually quite tolerable.

That said, I've funded decent amounts onto Bitaddress.org paper wallets with **NO** heartburn whatsoever.  Back when I found the bug I found, it's because I thought just like you, and personally took it upon myself to go and test the output of a run of 10,000+ private keys generated by bitaddress (part of why it happens to support a CSV generation feature - I asked for it so I could test its output).  Now that I can confirm that huge batches of keys test 100% correct against a completely independent implementation of the same thing (my Windows generator written in C#), I have no heartburn using it for large amounts.  In fact, I got paid $10k worth of BTC in person by someone not too long ago, and had a bitaddress paper wallet in my pocket, since I carry a couple fresh paper wallets just for this reason.  I ripped it in half, gave him the bitcoin address part, and said "here, here's my payment address".  It worked just like it was supposed to.

You know what wouldn't be a bad idea?  If I wrote the same CSV function in my Windows utility.  Meanwhile, if both pointbiz and I added a function to each of our apps just to verify the output of the other.  This way it would be easy for others to repeat that same test.

Thank you, this is very encouraging! I guess the only worry left is if the code generates keys in a way so that the founder has already generated the same keys. Since the code is open source this would be really stupid I guess, but again in this bitcoin world you can never be too paranoid. I don't know enough about cryptography & js to validate the code, has anyone done so ?

My biggest concern about using it to make a paper wallet is one that I don't think is really knowable just by looking at the code unless you're a real crypto expert: Just how "random" is its generator? I don't know if JavaScript exposes the system's random source (and I don't know as I'd want it to), so are there enough ways to move the mouse and such however it's getting its entropy that the private key really does have the full 256 bits of randomness, or at least enough bits for most applications?

Exactly what I'm thinking, it would be great if someone could shed some light on this issue.

[phelix]

I wonder how safe it was to cut the private key in half. I am aware that there are lots of issues with the qr code (error correction, data distribution).

say I cut this private key in two halves. Would it still be "hard enough" to figure out the whole private key for someone who got one of the halves?

5JfLL1e5GuESMu1B4SQNmUea  -  Mzyv2LWCevKBpMrGB3Yqd667JVC

[casascius]

My biggest concern about using it to make a paper wallet is one that I don't think is really knowable just by looking at the code unless you're a real crypto expert: Just how "random" is its generator? I don't know if JavaScript exposes the system's random source (and I don't know as I'd want it to), so are there enough ways to move the mouse and such however it's getting its entropy that the private key really does have the full 256 bits of randomness, or at least enough bits for most applications?

Exactly what I'm thinking, it would be great if someone could shed some light on this issue.

This could be handled just by altering the random number generation so that all bitcoin addresses were SHA256(entropy + salt), and where the user had to provide the salt into a text box.  The text box could be pre-seeded by random characters, but the user could always add a few more of his own, and that should settle it.

I did that in my own utility, but then changed it so that "salt" was automatically altered on the fly with the timestamps of mouse movement messages (which would be periodically turned into a hash of the list when the list got too big), so although the user couldn't control it directly, it was obviously unpredictable and good enough as salt.

[pointbiz]

My biggest concern about using it to make a paper wallet is one that I don't think is really knowable just by looking at the code unless you're a real crypto expert: Just how "random" is its generator? I don't know if JavaScript exposes the system's random source (and I don't know as I'd want it to), so are there enough ways to move the mouse and such however it's getting its entropy that the private key really does have the full 256 bits of randomness, or at least enough bits for most applications?

Exactly what I'm thinking, it would be great if someone could shed some light on this issue.

This could be handled just by altering the random number generation so that all bitcoin addresses were SHA256(entropy + salt), and where the user had to provide the salt into a text box.  The text box could be pre-seeded by random characters, but the user could always add a few more of his own, and that should settle it.

I did that in my own utility, but then changed it so that "salt" was automatically altered on the fly with the timestamps of mouse movement messages (which would be periodically turned into a hash of the list when the list got too big), so although the user couldn't control it directly, it was obviously unpredictable and good enough as salt.

The random number generator used on bitaddress.org is the same one used in bitcoinjs-lib. The implementation is originally from Tom Wu:
http://www-cs-students.stanford.edu/~tjw/jsbn/

I appreciate the concern regarding how much entropy is collected. The current random number generator has been producing bitcoin addresses for 1.5 years without any known cases of stolen funds due to someone finding a flaw in the generator.

Further analysis should be done regarding the available techniques to collect entropy with JavaScript implementations. The code for the random number generator is in the "SecureRandom" function and the UI code which triggers the seeding is in "ninja.seeder". I welcome any github forks that improve the entropy collected.

[casascius]

I wonder how safe it was to cut the private key in half. I am aware that there are lots of issues with the qr code (error correction, data distribution).

say I cut this private key in two halves. Would it still be "hard enough" to figure out the whole private key for someone who got one of the halves?

5JfLL1e5GuESMu1B4SQNmUea  -  Mzyv2LWCevKBpMrGB3Yqd667JVC

For all practical purposes, someone who only had half of a private key has nothing at all.  Now don't publish it on the web or anything if it's worth a decent amount of money, but if it's split between you and a friend, half is safe.

[pointbiz]

v2.3
https://www.bitaddress.org/bitaddress.org-v2.3-SHA1-1d067dc4f3103622ca9de332c3c86fc57d76ec83.html
 - Vanity Wallet now supports compressed keys.
 - Elliptic Curve and Bitcoin.ECKey libaries now support compressed keys.
 - English Json used for translations is now output to a textarea when
   you run the unit tests.
 - more unit tests, use ?unittests=true to run them.