Can bitaddress.org be trusted? (academic question)

[TookDk]

I know this topic has been discussed many time... I want to hear your opinion about the private address generation algorithm on https://www.bitaddress.org/.

I been looking at different methods to SECURE funds in a paper wallet (for a academic study).
My conclusion is that offline generation with a dump of https://www.bitaddress.org/ is straight forward and easy to use - and secure if you follow certain procedures.

Lets assume that I am super paranoid..
- Download https://www.bitaddress.org/ to a new USB stick
- Download Ubuntu to a new stick.
- Boot Ubontu on computer that is located in a soundproof Faraday cage with black curtains around - with no connection to any kind of network.
- Generate wallets - copy with pen/paper (or print through a printer on the USB port).
- Destroy all your equipment after.

.... am I missing something? (please point out if yes)

The question is: can bitaddress.org be trusted?

I have not studied the code - but if the seed are not completely deterministic, then will it be possible to re-generate the private address or at least limit the range to bruteforce.
What is your opinion, can https://www.bitaddress.org/ be trusted in regard to making completely random private keys?
 

[Remember remember the 5th of November]

I suppose you need to trust that the JS is not intentionally modified to use weaker PRNG/seed. Or that your browser is not compromised to provide less entropy.

[RoxxR]

I really wish we had something more simple available for this kind of purpose.
bitaddress.org is nice but the complexity of the source code is too high for most
users (even tech-savvy ones) to casually review. This is why we are getting
threads like this one every other week...

[Remember remember the 5th of November]

Might want to give Nobrainr a spin. It's a small python private key generator. Also supports physical dice input.

[RoxxR]

Might want to give Nobrainr a spin. It's a small python private key generator. Also supports physical dice input.

Thanks, I'm aware of it, but I don't want to fiddle with brainwallets... I'm looking for something that can generate plain standard key pairs. Couldn't find anything simple enough, but I'll keep searching...

EDIT: Also, I'm now getting a scary certificate warning (in Chrome) when going to https://www.bitaddress.org.
Not sure what this is all about, but it should be fixed as soon as possible.

[ajax3592]

Some of the best people in Bitcoin industry advised me to use that numbered method mentioned in the OP. It should work just fine, I guess.

[XBBlade]

Make sure printer isn't connected to internet in any way. Maximum security!

[BittBurger]

An important note:

As I understand it, after you generate your bitaddress.org private key, there is nothing stopping you from rearranging the letters manually and regenerating, while offline.

In such an event, there is no way on earth any third party could know your key.

You've effectively customized it.

[Evil-Knievel]

This message was too old and has been purged

[Raoul Duke]

Actually, I think your method is just as secure as using bitaddress.org itself. But if it lets you sleep better I would do it exactly like you said.

However, I still have the feeling that cracking such addresses ist still not impossible. It just takes a lot of effort.

OK. Do it. Lots of money await you. Why wait.

[RoxxR]

Wow, are you really saying that any cold storage address that was created using bitaddress.org until now can be easily cracked? That's huge news, most of the veteran users seem to recommend it. 

[Jason]

The huge problem is:

Code:

while (sr.pptr < sr.poolSize) {  // extract some randomness from Math.random()
			t = Math.floor(65536 * Math.random());
			sr.pool[sr.pptr++] = t >>> 8;
			sr.pool[sr.pptr++] = t & 255;
		}

The 256 byte pool gets filled with random values. Bad that they always ass the random number twice. That actually reduced the entropy by 50%.
Also, unless the random generator hits exactly 65536, the >>>8 (right shift by value always has a 0 bit in the front.

There is nothing wrong with the code you present above.  Assuming Math.random() returns a random float or double such that 0 <= Math.random() < 1.0, then the code is perfectly correct and your analysis is completely wrong.  You need to look more deeply into the code for Math.random() if you want to find any issues with address entropy.

[Evil-Knievel]

This message was too old and has been purged

[Evil-Knievel]

This message was too old and has been purged

[Terk]

65536 * Anything below 1 shifted right by 8 will result in a number smaller than 255.

255 * anything below 1 will also result in a number smaller than 255. I'd say that out of 256 numbers which you are able to write using an unsigned byte, 255 will be smaller than 255 and that's perfectly fine.

Ass 255 has a bit representation of 11111111. All numbers below 255 have a 0 in the first bit.

Have you tried to write down let's say 253 in binary recently?

[Evil-Knievel]

This message was too old and has been purged

[Jason]

Jason, i think you misunderstand something.

65536 * Anything below 1 shifted right by 8 will result in a number smaller than 255. Ass 255 has a bit representation of 11111111. All numbers below 255 have a 0 in the first bit. So unless Math.random() exactly hits 1.0 we have a trementously reduced entropy.

65536 * 0.999984741 (a floating point value less than 1) = 65535.
65535 >> 8 = 255

Maybe try this out for yourself with a short C/C++ program and see for yourself!

[Evil-Knievel]

This message was too old and has been purged

[Terk]

Terk, I already retracted my comment. However we still have only half the entropy that would be possible because of the duplicates in the state array.

Actually I think you're wrong on this as well. See:

The huge problem is:

Code:

while (sr.pptr < sr.poolSize) {  // extract some randomness from Math.random()
			t = Math.floor(65536 * Math.random());
			sr.pool[sr.pptr++] = t >>> 8;
			sr.pool[sr.pptr++] = t & 255;
		}

The 256 byte pool gets filled with random values. Bad that they always ass the random number twice. That actually reduced the entropy by 50%.

t >>> 8 takes 8 higher bits of 16-bit number and shifts them to become 8 lower bits while zeroing higher bits. So we now have an 8-bit number taken from 8 high bits of the previous 16-bit number.

t & 255 zeroes higher bits of the 16-bit number. So we now have an 8-bit number taken from 8 low bits of the previous 16-bit number.

To visualize this, let's mark these 16 bits with 0...F numbers. You have a 16-bit number 0123456789ABCDEF (where each 0...F sign is a number of the bit).

t >>> 8 makes it 0000000001234567 = 01234567
t & 255 makes it 0000000089ABCDEF = 89ABCDEF

The code doesn't use the same number twice.

[Jason]

Terk, I already retracted my comment. However we still have only half the entropy that would be possible because of the duplicates in the state array.

This is also false.  Assuming t is an int (I don't see the declaration in the code), then it is (on any modern machine) 32-bits in size.  Thus is should have a random value between 0 and 65535 in it after the Math.floor() statement.  Then the next two lines of code split this 16-bit value into two 8-bit bytes and add them to the array of random numbers.  In most cases, these two values will not be the same.

Example:

Assume t = 12345
Then t>>>8 = 48 (the first byte)
And t&255 = 57 (the second byte)

You should run the code and see this for yourself before raising it here.