Bitcoin Forum
June 22, 2024, 03:25:20 PM *
News: Voting for pizza day contest
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Can bitaddress.org be trusted? (academic question)  (Read 2264 times)
TookDk (OP)
Legendary
*
Offline Offline

Activity: 1960
Merit: 1062


One coin to rule them all


View Profile WWW
December 02, 2013, 02:38:21 PM
 #1

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?
 

Cryptography is one of the few things you can truly trust.
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1862
Merit: 1011

Reverse engineer from time to time


View Profile
December 02, 2013, 02:41:10 PM
 #2

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.

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
RoxxR
Full Member
***
Offline Offline

Activity: 208
Merit: 148


View Profile
December 02, 2013, 03:08:49 PM
 #3

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
Legendary
*
Offline Offline

Activity: 1862
Merit: 1011

Reverse engineer from time to time


View Profile
December 02, 2013, 03:13:41 PM
 #4

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

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
RoxxR
Full Member
***
Offline Offline

Activity: 208
Merit: 148


View Profile
December 02, 2013, 05:04:34 PM
 #5

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
Full Member
***
Offline Offline

Activity: 210
Merit: 100

Crypto News & Tutorials - Coinramble.com


View Profile
December 02, 2013, 05:49:15 PM
 #6

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.

Crypto news/tutorials >>CoinRamble<<                            >>Netcodepool<<                >>My graphics<<
XBBlade
Member
**
Offline Offline

Activity: 98
Merit: 10


View Profile
December 02, 2013, 06:16:13 PM
 #7

Make sure printer isn't connected to internet in any way. Maximum security!
BittBurger
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1001


View Profile
December 02, 2013, 07:39:33 PM
 #8

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.

Owner: "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
View it on the Blockchain | Genesis Block Newspaper Copies
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1260
Merit: 1168



View Profile
December 02, 2013, 08:04:51 PM
Last edit: April 17, 2016, 09:28:49 PM by Evil-Knievel
 #9

This message was too old and has been purged
Raoul Duke
aka psy
Legendary
*
Offline Offline

Activity: 1358
Merit: 1002



View Profile
December 02, 2013, 08:11:31 PM
 #10

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
Full Member
***
Offline Offline

Activity: 208
Merit: 148


View Profile
December 02, 2013, 08:58:45 PM
 #11

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
Member
**
Offline Offline

Activity: 114
Merit: 10


View Profile
December 02, 2013, 09:02:15 PM
 #12

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

BM-2D7sazxZugpTgqm3M2MCi5C1t8Du8BN11f
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1260
Merit: 1168



View Profile
December 02, 2013, 09:03:11 PM
Last edit: April 17, 2016, 09:28:43 PM by Evil-Knievel
 #13

This message was too old and has been purged
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1260
Merit: 1168



View Profile
December 02, 2013, 09:10:26 PM
Last edit: April 17, 2016, 09:28:37 PM by Evil-Knievel
 #14

This message was too old and has been purged
Terk
Hero Member
*****
Offline Offline

Activity: 616
Merit: 522



View Profile
December 02, 2013, 09:12:07 PM
 #15

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
Legendary
*
Offline Offline

Activity: 1260
Merit: 1168



View Profile
December 02, 2013, 09:14:42 PM
Last edit: April 17, 2016, 09:28:31 PM by Evil-Knievel
 #16

This message was too old and has been purged
Jason
Member
**
Offline Offline

Activity: 114
Merit: 10


View Profile
December 02, 2013, 09:15:38 PM
 #17

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!

BM-2D7sazxZugpTgqm3M2MCi5C1t8Du8BN11f
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1260
Merit: 1168



View Profile
December 02, 2013, 09:20:42 PM
Last edit: April 17, 2016, 09:28:25 PM by Evil-Knievel
 #18

This message was too old and has been purged
Terk
Hero Member
*****
Offline Offline

Activity: 616
Merit: 522



View Profile
December 02, 2013, 09:23:11 PM
 #19

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
Member
**
Offline Offline

Activity: 114
Merit: 10


View Profile
December 02, 2013, 09:23:31 PM
 #20

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.

BM-2D7sazxZugpTgqm3M2MCi5C1t8Du8BN11f
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!