Topic: [ANN] bitaddress.org Safe JavaScript Bitcoin address/private key - page 27. (Read 153371 times)

v2.4
https://www.bitaddress.org/bitaddress.org-v2.4-SHA1-1d5951f6a04dd5a287ac925da4e626870ee58d60.html
 - French translations thanks to blockgenesis.

Up next is the BIP38 stuff.

i can't reproduce it on any other machine i've tried either... this old WinXp pc from the 80's must be having it's own issues.

I can't reproduce in chromium Version 24.0.1312.56 Ubuntu 12.10 (24.0.1312.56-0ubuntu0.12.10.3).

Bug Report:

the QR codes turn solid black after exactly 18 clicks of the Generate New Address button on the first tab

using Chrome Version 24.0.1312.57 m


...this bug has then also carried over to liteaddress.org

edit: i realised this is actually working fine in regular Chrome, but the bug appears in incognito mode only.

what about putting your code on github? It is kinda hard to trust an archive from dropbox.

Sending funds does not work any more with the MtGox client: https://bitcointalksearch.org/topic/mtgox-mobile-android-client-error-method-is-disabled-140739

I think we need to get support for scanning private keys into some other client.

I can verify that the BitAddress.org website has been updated and returns the same HTML from the commit with the description v2.3 (1d067dc4f3103622ca9de332c3c86fc57d76ec83) 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
1d067dc4f3103622ca9de332c3c86fc57d76ec83  -

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


Then from my bitaddress.org repo:

$ git checkout master
$ git pull
$ git log --pretty=oneline|grep "v2.3"
54523d36b2680e8ec231c95b776bc2259f6bb328 v2.3 Vanity Wallet now supports compressed keys

$ git checkout 54523d36b2680e8ec231c95b776bc2259f6bb328
$ git rev-list --max-count=1 HEAD
54523d36b2680e8ec231c95b776bc2259f6bb328

$ sha1sum bitaddress.org.html
1d067dc4f3103622ca9de332c3c86fc57d76ec83  bitaddress.org.html

I might throw up a bounty to do an "intermediate code generator" as well.  (this won't be hard - just another simple recipe using scrypt,sha256,base58)

Here is what I imagine... another tab that says "Encrypted Wallets"

On the tab there would be two functions: generate intermediate code, and decrypt encrypted wallet

THe intermediate code takes a passphrase and makes a code (or series of codes) out of it.  The code can be used by someone else to generate bip38-encrypted paper wallets without knowing the passphrase.  Intermediate code generator takes a passphrase as input, and outputs a string that simply encodes 4 bytes of salt, 4 bytes of a combined "batch" and "sequence" number, and one compressed EC point.  The EC point is G * sha256(scrypt(passphrase, salt, 16384, 8, 8 ) + batch+sequence bytes) or something substantially similar.  The sequence number can be incremented to create more intermediate codes from the same passphrase without repeating the scrypt.

Thanks!

I just read the brain wallet thread you mentioned. My thoughts are that yes most likely I will add a new brain wallet algorithm involving scrypt with some of the techniques mentioned by casacius and Gavin. SHA256 will be available via a drop down for choosing your algorithm.

I like to follow this topic and I only want to implement standards or would be standards. Some people are using various big integer to word list algorithms but none is advocating theirs as a standard nor do they explain why they use non standard lists etc.

Casascius has been the biggest supporter of bitaddress.org since the beginning. He has put up bounties to get BIP38 which uses scrypt into JS and it will be the next feature on bitaddress.org

I love bitaddress.org, and I consider it the Gold-Standard - er, the Bitcoin-Standard site for creating paper wallets.

That said, I see that you are using SHA256(passphrase) for the Brain Wallet.  Also, if I am following threads and people correctly, it seems that you respect the opinions of casascius.  He is advocating for a standard Brain Wallet function (based on scrypt as the key derivation algorithm).

https://bitcointalksearch.org/topic/m.1484171

Any thoughts?  Do you think you will be updating bitaddress.org?  And if so, how will you handle previously generated brainwallets with SHA256 - hopefully we'll still have easy access to them on bitaddress.org.


Also, I have an idea for something a little different, but I am heavily using your bitaddress.org 2.2 code.  (I'll snag 2.3, now that I see it's out there.)
Thank you for making it easily licensed.   I am actually going to try to keep your code, byte-for-byte, intact, so that people can peer-review my derivation faster (since many eyes have already reviewed your code.)

Thanks again!

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.

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.

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.

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.

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

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 ?

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

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?

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.

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.

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.