ANN: Python paper wallet generator with strong randomness

[TookDk]

Do anybody know if a parser script exist that can run offline, to check that the public adr. correspond to the private adr. ?

It would be nice to double check that the private key and public key match, before you transfer a lot of BTC.
Ofcause you can redeem your private key - but then has the key been exposed.

Save a local copy of bitaddress.org? (it's just one HTML file with all necessary javascript included)

Thank you for reply's... (ofcause, doh).

OP: sorry I have messed up you thread, I guess my question about private key validation and retrieval was a bit of topic.
I can delete my posts about the private key validation if you like, just PM.

[deepceleron]

I could not get Electrum to import the private key.
I tried the same private key with blockchain online wallet, it worked beautifully.

What method you use/recommend to redeem your private key?

Compressed addresses can reduce your fees by half, in addition to the reduction in blockchain size. I don't know if the status of Electrum has changed in a year, it seems not:

no, Electrum does not support compressed keys (except for verifying signed messages)

(Edit: it does, you just need to go to the correct screen in the current version.)
-

Darn it. I'm on XP (32 bit.)

Well, you have just been protected from yourself!:
http://en.wikipedia.org/wiki/CryptGenRandom

In practice though, a reduced strength OS crypto won't matter; just typing 32 unmemorized keypresses, which alone are combined with another long string, appended to itself eight times, and put through SHA512, is stronger than the first "brainwallet" (and that's just one line of the script, the same line which XORs that with the result of about 1917 other hashes. And that's just to generate 1/3rd of the entropy used by the random generator).

Install Python, it's no big thing, and a world will open up for you.
-

Merry Christmas deepceleron

Much thanks, this is not overlooked!

[phelix]

I get 512bit user entropy based on keypress times, with keypress values also used *8 (but not an integral component). I don't get the strict "time" between keypresses, there's a time->hash-driven variable length loop that runs after each keypress before time-poll to make CPU speed and system interrupts a factor, then I convolute the time. I seed the OS urandom with this user entropy and make a SHA256 hashed OS-based random key whitened with python's Mersenne Twister from oracle back to random bit depth. That's good enough, but then I re-seed the OS entropy pool every 1024 bits with time and user-based entropy plus hashes, then I XOR with a differently-obfuscated SHA2 of system random,  and then I XOR with processor-time based and clock based time sources stretched to put 512bits of noise in the hash. Repeat 100 times. The code is easier to read than the explanation.

I think the code is too complicated to be easily verified. Why don't you concatenate the entered characters, some time (delta) string and urandom string together and sha256 the hole thing?

[integrity42]

I get 512bit user entropy based on keypress times, with keypress values also used *8 (but not an integral component). I don't get the strict "time" between keypresses, there's a time->hash-driven variable length loop that runs after each keypress before time-poll to make CPU speed and system interrupts a factor, then I convolute the time. I seed the OS urandom with this user entropy and make a SHA256 hashed OS-based random key whitened with python's Mersenne Twister from oracle back to random bit depth. That's good enough, but then I re-seed the OS entropy pool every 1024 bits with time and user-based entropy plus hashes, then I XOR with a differently-obfuscated SHA2 of system random,  and then I XOR with processor-time based and clock based time sources stretched to put 512bits of noise in the hash. Repeat 100 times. The code is easier to read than the explanation.

I think the code is too complicated to be easily verified. Why don't you concatenate the entered characters, some time (delta) string and urandom string together and sha256 the hole thing?

Yes thats probably enough entropy, and makes for easier to read code. Any thoughts on a simplified version?

[deepceleron]

Any thoughts on a simplified version?

My main goal was to fuzz all random sources way beyond reproducibility, with time being the primary source. Time is envisioned somewhat repeatable (think restart a no realtime-clock device with no entropy gathering and immediately run this) and has 32 bits, but less than 16 could be considered entropy-like. I already made a large simplification for the sake of readability, there's not much to remove that wouldn't defeat the goal. Remember, there are demonstrations of cryptanalysis of hardware RND bias by affecting heat generation through remotely running processes on a machine.

A white paper on the motivation and methods used may facilitate review without reading code. Here's a summary of
methods, in order they are used:

clockbase(): poll raw system timers twice,
clockrnd(): 512 bit entropy by random-length-loop of various hashings of clockbase(),
platform_check(): ensure repeating calls to clockrnd() never return same result,
keyboard_entropy(): accumulate XORs of clockrnd() before and after every keypress, XOR SHA512 of stretched presses,
random_key(): entropy by keyboard_entropy() + urandom state + time
    seed system random generator (urandom) with entropy
    privkey initial value by 256 bits urandom XOR sha256 of 512 bits urandom
    then random 64-128 loops of:
        XOR random 256 bit window of SHA512 of clockrnd()+clockrnd()+entropy
        XOR random 256 bit window of SHA512 of 512 bytes urandom
        XOR 256 more bits from 2nd urandom object
        reseed urandom with SHA512 of the first two XORs plus entropy

By the time we're done we've asked for the epoch time or processor time about 6000 between 43492-382796 times (or potentially millions on OSX), and done about that many hashes. Then we make a Bitcoin address from that garbage if it is a valid private key...

Or for users: bang on keys, get address.

In other news, I have gotten Python-only BIP38 passphrase encryption running from a single script. That's native AES, PBKDF2, SCrypt; at least Python includes SHA1 and 2.  It takes about nine minutes to produce the encrypted private key on one core of Core2Quad 2.8GHz...

[phelix]

Code:

entropy = raw_input()
entropy += os.urandom(32) + str(random.randrange(2**256)) + str(int(time.time())**7)  # from Vitalik
entropyHash = hashlib.sha256(entropy).hexdigest()

Is this so much less safe than your version to justify 150 lines of code?

Don't get me wrong, I really like the general idea. 

[deepceleron]

Code:

entropy = raw_input()
entropy += os.urandom(32) + str(random.randrange(2**256)) + str(int(time.time())**7)  # from Vitalik
entropyHash = hashlib.sha256(entropy).hexdigest()

Is this so much less safe than your version to justify 150 lines of code?

Don't get me wrong, I really like the general idea.  

That:
1. uses urandom, we don't know if it's good. Actually, we know it's not good.
2. uses the initial state of Mersenne Twister, likely deterministically related to the previous urandom
3. uses the current time, not unfathomable to gather what it's state might have been:
print time.time();print time.time()
1386957154.74
1386957154.78
4. uses SHA256, which is pretty darn strong as long as you don't let users put data through it. Created by the NSA.

[phelix]

Code:

entropy = raw_input()
entropy += os.urandom(32) + str(random.randrange(2**256)) + str(int(time.time())**7)  # from Vitalik
entropyHash = hashlib.sha256(entropy).hexdigest()

Is this so much less safe than your version to justify 150 lines of code?

Don't get me wrong, I really like the general idea.  

That:
1. uses urandom, we don't know if it's good. Actually, we know it's not good.
2. uses the initial state of Mersenne Twister, likely deterministically related to the previous urandom
3. uses the current time, not unfathomable to gather what it's state might have been:
print time.time();print time.time()
1386957154.74
1386957154.78

Now that I look at it the use of time() and int() above seems rather bad. The clock() function you use is very interesting.

But if I let my dog play with the keyboard for a while to gather entropy it should not be a problem. Everything else is more like a salt then.

4. uses SHA256, which is pretty darn strong as long as you don't let users put data through it. Created by the NSA.

The idea is that if SHA256 will break then your Bitcoins will plummet anyway...


Anyway it's great that you do profound thinking about these issues that form the very basis of Bitcoin.

[deepceleron]

Big update. Much work. Encryption. Some Options. No changes to the random stuff or normal address generation.

There's bitcoins a few posts back if you want to steal them...(aand they're gone!)

[Abdussamad]

Compressed addresses can reduce your fees by half, in addition to the reduction in blockchain size. I don't know if the status of Electrum has changed in a year, it seems not:

Electrum does support compressed keys now. Since 1.9 I think.

In other news, I have gotten Python-only BIP38 passphrase encryption running from a single script. That's native AES, PBKDF2, SCrypt; at least Python includes SHA1 and 2.  It takes about nine minutes to produce the encrypted private key on one core of Core2Quad 2.8GHz...

Why is this slower than the bitaddress implementation? Both python and javascript are interpreted languages so they should be equally fast, right?

[deepceleron]

Why is this slower than the bitaddress implementation? Both python and javascript are interpreted languages so they should be equally fast, right?

Python can be much faster when it uses compiled libraries that are interfaces to c machine code behind some of the math; however I made the script with written-in-Python code, not especially optimized (if it's even possible), simply because I want to provide something as a single script for a live cd/offline wallet that doesn't require installation of obscure sources. The implementations of AES and SCrypt are, like a lot of Python, largely academic, since faster implementations will always be in native code. Just in time compilers like cpython and PyPi can accelerate things multiple times, just like Javascript JIT compilers in browsers, and have support for multithreaded greenlets, although the anti-GPU features of scrypt are just as much anti-Python features.

For the windows exe I could probably cheat and just give you fast libs.

[Dabs]

Okay, I like the fast libs.

Big update. Much work. Encryption. Some Options.

I was almost afraid you would say "very currency, much wow!" or something crazy like that. Seems to be the fashion the past two weeks.

[TookDk]

Okay, I like the fast libs.

Big update. Much work. Encryption. Some Options.

I was almost afraid you would say "very currency, much wow!" or something crazy like that. Seems to be the fashion the past two weeks.

+1

"Such update. Much work. Much Encryption. Many Options. WOW"

[deepceleron]

Oops, I've had the wrong sha256sum in the first post since January, updated. I guess that shows how many people have actually tried this out...

[TookDk]

Oops, I've had the wrong sha256sum in the first post since January, updated. I guess that shows how many people have actually tried this out...

I tried out your script, back in January, but never actually tested the keys generated with live coins.
I think this script is very useful, I hope to use it for something serious one day.

[Abdussamad]

At one point there were 2 sha256 hashes in the OP one of which was correct. Then a few months ago the correct one disappeared.

[Dabs]

What's the SHA256 for the Windows EXE?

[deepceleron]

What's the SHA256 for the Windows EXE?

Verified my local compile vs what is on my site (still identical), and updated first post with sha256sum and md5sum info, thanks! (also just noticed the exe file properties still say version 1.1; this is from the py2exe script which I didn't update when compiling..)

[Dabs]

Thanks. I'm going to use it for some heavy duty BTC transactions.

[r3c4ll]

Thanks for the script!