Topic: How Much Trust does Bitaddress.org deserve? (Read 5057 times)

Edit: Sorry, I understand now that the program is continuously monitoring mouse movements while you have the page loaded.

Thats pretty cool.

Indeed. I posted that command line so anyone can verify that the private key generated on your page really and truly is the sha256(passphrase). Other than that, it does not add anything.

I think moving the "brain wallet" functionality to a separate tab with the right label is an excellent idea.

That is already possible on bitaddress.org on the Wallet Details tab. I'm thinking of adding a "Brain Wallet" tab to bring that feature to peoples attention.

Casascius is offering me a bounty to upgrade the Paper Wallet tab to support deterministic wallets based on a passphrase.

Regarding the random number generator, for those sufficiently paranoid, I would advise not to use the first address generated and to move the mouse around for two minutes, then generate a new address. The mouse movements continuously add to the random seed pool while you are on the page.

Casascius also has entropy from keyboard input to the random number generator on his bounty list.

That sounds like a great idea, providing the java script webpage you create, is run in an environment where nothing is stored, such as a ubuntu live cd...

So to protect myself from that possiblity Im thinking I will create my own java script webpage with the following command, courtesy of the poster Anu


That will generate a private key from a passphrase. Then I use Bitaddress offline to generate the correponding public key, and bitcoin address.

Yes--that!  The situation you describe, could also turn out to be the case without any willful intent by the developer:  if weaknesses were subsequently identified in the crypto libraries the code is calling to generate random numbers, the address space it creates, could turn out to be too small.  Without anyone involved aware of that fact when the addresses are being generated.  IMHO, it would be more secure to simply mash on the keyboard a while than to rely on the crypto libraries not having some flaw that is subsequently uncovered.

I have thought a fair bit about this risk, and I wish it went a step further.

It would be nice if the script did its own random number generation as it does, but also took a string of input from the KEYBOARD (not mouse), and from that, generated a second pseudo-random number stream in a predictable, easy to audit manner, and XOR'd the two streams together.  By "predictable", I mean, for example, each 32 byte chunk of the stream is calculated as merely SHA256(string + n), where n increments for each chunk.  (This is how I generate random number for Casascius Coins, as a hedge against the potential for a flaw if one were to be found in the Microsoft library RNG I was using, despite it being documented as "cryptographically secure").

Also it's worth noting: the original author of BitAddress.org has historically been very responsive to making improvements in exchange for donations and bonuses, and I feel I have had a satisfactory effect on just the current functionality by stating what I think it needs and offering to donate.

Nimda, you are right, I have the most confidence in the way Bitcoin-Qt generates private keys, because it has been around the longest and seems to be passing the test of time.  For anything newer, I want to hear how widespread their use is & what peoples' experiences are before putting my trust in them & ideally, someone who has looked at the code and thought about this question.   & part of the purpose of my post was to encourage anyone with the ability & interest, to look at Bitaddress.org's javascript, or to share the results if they had done so in the past.

But I do respect that code can be very difficult for people to read and the list of people able to pick out something that was purposely obfuscated by the writer, and who have the inclination and time to do it, is probably pretty short!

Thanks, BitcoinTraderIE

One thing that applies to things like Bitcoin and, to a lesser extent, bitaddress.org is that someone will hopefully find flaws. For example, if Bitcoin-Qt contained code which allowed Gavin to access your coins from a remote server at will, don't you think someone would have found it by now? Wouldn't at least one of the thousands of users of Bitcoin have spoken up? Even if their claims were on Freenet or a Tor hidden service? It's been years, and I still have yet to hear such a claim. Thus, without doing more than a cursory review of the code, I feel safe trusting Bitcoin-Qt with large amounts of money (provided I do backups ). As more people look at Bitaddress.org and find nothing wrong with its source, the other users can become more assured that it is a safe tool to use.

Thanks for writing some code to generate addresses.  For me, it's true that I have to start out NOT trusting that the random number generation is without any flaws.  But as a non-programmer of java or javascript, I must rely on the opinions of others more qualified to look at the exact lines of code creating the addresses, and who, hopefully, also understand the crypto and the libraries the javascript is using.  I see mandatory security updates to the crypto libraries of python in my Ubuntu distribution regularly, but don't understand the implications for applications that make use of the libraries.  

I'm reading some of the other members talking about generating the input to hash on the bitaddress.org site, as meaning that, it's better to sidestep my question about how the site creates random numbers and generate the string yourself with your own entropy, whether you do it as a "brain wallet" or not.  I have verified that the site really does give the sha256 hashes of what the user puts in the text box.

I have been surprised of how trusting people on the forum seem to be of the address generation process for private keys in general, from any of the applications that do this.  Especially considering that security experts such as Bruce Schneier have observed years ago that the US government most likely deliberately introduced standards for "random" number generation for elliptic curves, (Dual_EC_DRBG), such that the author of the standard (NSA in this case), was in a position to posses secret keys would make the "random" outputs, predictable, which would make the encryption trivial for someone in possession of the secret keys to crack.  Here is the article http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115

& I understand sha256 itself arose from a nsa standard.  I would think if anyone on the planet has something better than brute force to break that hash, or to break a random number source, it would be them, especially when they are coming from standards they themselves authored.   I'd be really interested in hearing from any of the developers of bitcoin software that know all about these issues and have thought about their implications for the applications they write.

Thanks for that info. Donation sent to address in your sig.

This is really the wrong question. A better one is: Assuming you don't trust it, how much work does it require to trust it?

I have saved a copy of the site and even hacked a bit on the code but I wouldn't send a new user blindly to the site claiming that it's forever safe.

For this purpose, I am hosting a minimal address generator that uses python at github.
It's much less code to read and if a change is made you'll see it in the commit log.

http://github.com/weex/addrgen

Not at all. The thing is supposed to be a brain wallet. That means it's in your brain, and only there.

And security through obscurity is not always bad. For example I use words from 3 languages in my (real) passphrase, 2 of which are obscure indeed - the other is Thai. Good luck with your dictionary attack!

Using publicly available information and semi-private information alone is a bad idea, yes, but it can add a few bits of entropy if you use it along with a good secret. Hell, just the order that the information is used is worth 1-2 bits of entropy (depending on how much information you include).

Also, passwords as a whole are security through obscurity, so we might as well just give up, then, because we have to assume that all attackers know the secret, too.

This.  I do hope the author considers expanding the site.  The ability to generate a printout of encrypted private keys for cold wallets would be a useful feature.  The ability to generate a single address or sequence of addreses from a passphrase would also be a useful feature. 

So my original post was accurate.  Security through obscurity.

One should assume the attacker knows everything but the secret.  

That includes:

• algorithm
• salt
• number of rounds

• other technical details

Strong cryptography is still strong even if all of the above is given to the attacker.  It is strength from numbers not strength from obscurity.


There is no value in obscuring the salt. While it is true the attacker not knowing the salt doesn't make it weaker it doesn't make it stronger.  On the other hand using an input with limited entropy as a salt is a cryptographic flaw.  A driver's license number has at most 30 bits of entropy which is pitifully weak given the computing power of today's systems.  Modern salt should be at least 64bit (have at least 17 trillion times as much entropy) and honestly given the "cheapness" of larger bits there is no reason to not use 128 bit (almost a quadrillion, quadrillion times as much entropy).[/list]

Yes, the real reason to use bitaddress.org for brainwallets is how it transforms the private key into wallet import format and gives you the public key. Without it, have fun computing secp256k1 and RIPEMD-160 and base58 and all of that...

One more time before I give up: IT DOESN'T HURT IF THE CRACKER DOESN'T KNOW THE SALT

Because this command simply creates a "random" 256-bit number, which can be interpreted as a private key. This command doesn't give you the address that belongs to that key so you cannot send funds to it. And it doesn't give you the key in WIF format which is what you need to import it into a wallet - so you can spend it.

One more time before I give up.
THE CRYPTOGRAPHIC METHOD TO ENSURE THE ATTACKER CAN'T PERFORM A PRECOMPUTATION ATTACK IS SALT!
While an attacker may be able to precompute SHA256(password) he can't precompute SHA256(password+salt).  Where salt is a random 128 bit number.

Using things like personal information doesn't provide sufficient entropy.  While he may not be able to find your driver's license number a modern GPU could attempt every possible drivers license number in a second or two.  So you merely adding complexity without adding any real security.  More complexity increases the chance you will not be able to recover the private key later.   Say it is 20 years from now and you need to recover your private key.  Hmm was that (passphrase+name+driver's license) or was it (passphrase+drivers license+name)? Wait did I capitalize the name?  The driver's license has dashes now but did it have dashes 20 years ago?  Did the DMV ever change my driver's license?  etc. 

There is no cryptographic value to adding personal information to a passphrase.   We use salt to ensure the attacker needs to isolate and attack one passphrase. 

To be truly secure you need:
a) strong passphrase
b) salt of sufficient size (128 bit recommended)
c) private key derived from password using a multi-round process (PBKDF2, bcrypt, scrypt, etc)