Thanks. I am just a little paranoid.
I generated my addresses with 2.5.1 of bitaddress, and I used the bulk address tab
I generated about 10 addresses. I am just trying to figure out if they will be 100% or as close to 100% secure as possible
Any additional tips regarding address generation safety would be greatly appreciated.
Topic: Can bitaddress.org be trusted? (academic question) (Read 2264 times)
When generating new private keys, is it a good idea to do something like this?
generate a private key
enter that private key into wallet details tab
add & edit symbols, characters, and numbers to it
use the new private key it outputs?
generate a private key
enter that private key into wallet details tab
add & edit symbols, characters, and numbers to it
use the new private key it outputs?
If you only add symbols, characters, and numbers, and don't edit or delete any, and you get that popup that says "The text you entered is not a valid Private Key! Would you like to use the entered text as a passphrase and create a Private Key using a SHA256 hash of the passphrase?" then you probably aren't doing any harm and maybe even slightly improving things.
When you create a new private key using the hash of added numbers and symbols, does this add to the security vs just clicking generate? As it is truly random
To answer your last question first, I don't trust the random number generator in my OS, let alone when used from javascript running on a liveUSB. Fortunately, bitaddress.org lets you provide your own private key which you can randomly generate from a more trustworthy source of randomness.
I was thinking about something, what are the rules for generating your own WIF 51 characters base58 private address? Is the only rule that the first character in the string is "5" ?
In that case, it would be pretty straight forward to generate your own private key.
When generating new private keys, is it a good idea to do something like this?
generate a private key
enter that private key into wallet details tab
add & edit symbols, characters, and numbers to it
use the new private key it outputs?
Also, is it any better to use Armory or Bitcoin qt to generate private keys, as opposed to bitaddress.org.html?
generate a private key
enter that private key into wallet details tab
add & edit symbols, characters, and numbers to it
use the new private key it outputs?
Also, is it any better to use Armory or Bitcoin qt to generate private keys, as opposed to bitaddress.org.html?
I read something written by someone else here which said something about the possibility of a virus (which could be carried by the CD/DVD/USB-stick) which generates a pattern in your power usage which can be read by someone monitoring the power usage of your house. So if you want to be completely paranoid, you'll have to run the computer by battery, and either destroy the battery afterward or at least never again connect it to the grid. 
Now that is the right level of paranoia I am looking for
Thank you for all the input guys (thanks a lot).
My conclusion is that you need to run your own random generator (truly deterministic) and use it as a input to a script you understand and trust.
I heard about that casting dice is the most random way to generate a private key
Speaking of that, bitaddress.org now accepts dice input!
Also NoBrainr (the python command) supports that in a very simple way.
I heard about that casting dice is the most random way to generate a private key
This message was too old and has been purged
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.
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:
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%.
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;
}
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.
This message was too old and has been purged
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 * 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!
This message was too old and has been purged
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?
This message was too old and has been purged
This message was too old and has been purged
The huge problem is:
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.
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;
}
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.
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.
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.
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.
This message was too old and has been purged
Jump to: