The biggest problem with cold storage wallets is making sure that your address..

[no_alone]

Hello,
I'm finding a problem making sure my cold storage wallet is secure.. I find that the only loop hole in cold storage is making sure that the address generated in the offline pc are really random..
I can think of several issues:

1. a ubunto developer change the source code so that all users that create new address in bitcoin will create address from a pool of 200 million address  ( so each one will get a different one) but the developer know the keys for all of them

2. downloading a bitcoin-qt client that new address generated from this client is from a pool of 200 million address ( so each one will get a different one) but the bitcoin-qt developer/hacker will have the keys for all address.


What is the best way to be absolutely sure my address is random|?
Has anyone ever thought about this issue?


Thank You.

[grux]

This is a massive thing people look after. A ubuntu developer couldn't do something like that easily, as it would be extremely noticeable, and people would wonder what reason he had to do so. Sorta like what went down on the android bitcoin app, everyone was notified that it was using an insecure RNG that the developers choose . Rest assured, it's not going to be easy to rampantly harvest addresses like that as you described. There would be a notable amount of address collisions, and an insecure RNG in ubuntu would wreak havoc in other applications. The bitcoin client uses openSSL, which is trusted by companies who have way more at stake than bitcoin's current cap.

[justusranvier]

If you're doing cold storage and think that somehow involves Bitcoin-Qt you're doing something very wrong.

Use Armory for cold storage.

[flatfly]

A good way to bypass any RNG backdoors is to generate your random addresses using dice.
Several tools support that: NoBrainr (see link in signature), bitaddress.org, and a few others which you can find on this forum.

[gglon]

dice hack http://www.youtube.com/watch?v=Wq-MDBFolXs

[keystroke]

If you're doing cold storage and think that somehow involves Bitcoin-Qt you're doing something very wrong.

Use Armory for cold storage.

What's wrong with QT? It has been audited to an extreme. Armory is great with the paper wallets but putting a wallet.dat into cold storage should be ok.

[Automatic]

dice hack http://www.youtube.com/watch?v=Wq-MDBFolXs

That's way to cheaty for me, if I used that, well, let's just say primedice would be out of their reserve for a long time. I'm a good person, however, so, I'll just report it as a bug to 'em.

[GhostGum]

If you're doing cold storage and think that somehow involves Bitcoin-Qt you're doing something very wrong.

Use Armory for cold storage.

What's wrong with QT? It has been audited to an extreme. Armory is great with the paper wallets but putting a wallet.dat into cold storage should be ok.

I recommend against just using the wallet,dat file for your cold storage, as the wallet.dat format may change in future client versions, possibly loosing compatability with the current file layout (berkleydb vrsion incompatibilities, or dropping bdb entirely); making it a pain for you to read the keys from it.
Just dump the privkeys (or evern better, theres a dumpwallet command addded to bitcoin client which dumps out the wallets whole keyppool in a nice table for you).  and save that for storage,  pipe strait into openssl, or gpg, or whatever if wanna store encrypted or just to aviod writing raw key to disk/stdout...

[justusranvier]

What's wrong with QT? It has been audited to an extreme. Armory is great with the paper wallets but putting a wallet.dat into cold storage should be ok.

Can you sign transactions offline with Bitcoin-Qt?

[piotr_n]

Hello,
I'm finding a problem making sure my cold storage wallet is secure.. I find that the only loop hole in cold storage is making sure that the address generated in the offline pc are really random..
I can think of several issues:

1. a ubunto developer change the source code so that all users that create new address in bitcoin will create address from a pool of 200 million address  ( so each one will get a different one) but the developer know the keys for all of them

2. downloading a bitcoin-qt client that new address generated from this client is from a pool of 200 million address ( so each one will get a different one) but the bitcoin-qt developer/hacker will have the keys for all address.


What is the best way to be absolutely sure my address is random|?
Has anyone ever thought about this issue?


Thank You.

Generate a random key yourself (e.g. by hashing some random input) at the cold wallet PC and import it to your bitcoin-qt wallet using "importprivkey".

Or use a different bitcoin wallet - one that does not rely on a random number source which you don't fully trust.

[glitch003]

Hello,
I'm finding a problem making sure my cold storage wallet is secure.. I find that the only loop hole in cold storage is making sure that the address generated in the offline pc are really random..
I can think of several issues:

1. a ubunto developer change the source code so that all users that create new address in bitcoin will create address from a pool of 200 million address  ( so each one will get a different one) but the developer know the keys for all of them

2. downloading a bitcoin-qt client that new address generated from this client is from a pool of 200 million address ( so each one will get a different one) but the bitcoin-qt developer/hacker will have the keys for all address.


What is the best way to be absolutely sure my address is random|?
Has anyone ever thought about this issue?


Thank You.

This problem is what I created Piper to solve.  Piper is a permanently offline hardware paper wallet generator and printer and so much more powered by the Raspberry Pi platform.  It gets it's randomness from a hardware random number generator that uses thermal gradients to produce entropy. 

How do you know it safe though?  It uses community-accepted methods to do the key generation, and it's open source, so you can easily check the code yourself and make sure it's not doing anything sketchy.  All Piper software is written in python so the source is included, and it's not a lot of python so I believe most programmers could fully audit the code in a short period of time.  The only non-python part of the key generation is vanitygen.  But the source for vanitygen is included, and you can easily build it by typing "make' and then compare the binary you just built to the one used by Piper by doing an MD5 hash on both.  You can also compare the code on Piper to the code in the vanitygen github repo to make sure there is no foul play there as well. 

So if you want a turnkey solution to this problem, check out https://piperwallet.com

[piotr_n]

It gets it's randomness from a hardware random number generator that uses thermal gradients to produce entropy. 

I guess that is exactly what he is afraid of.
All these hardware random number generators are completely unauditable - its even worse than with the software.

[grue]

flip 256 coins, then use those bits (heads/tails) as private keys.

[piotr_n]

flip 256 coins, then use those bits (heads/tails) as private keys.

that's also a method.

but I think hitting a hundred of random keys on your keyboard - and then getting e.g. sha256 hash of it, is usually much faster.
just don't use a wireless keyboard

[glitch003]

It gets it's randomness from a hardware random number generator that uses thermal gradients to produce entropy. 

I guess that is exactly what he is afraid of.
All these hardware random number generators are completely unauditable - its even worse than with the software.

Unauditable?  Check this tool out: http://www.phy.duke.edu/~rgb/General/dieharder.php

The RNG in Piper has passed all 26 tests in that program that have a rating of "good".  The "good" thing is because the developer also includes tests that are questionable, so we only tested Piper on the ones he rates as "good".  Here are the results: http://piperwallet.com/dieharder-results.txt

So the RNG in Piper has in fact been statistically audited for secure randomness and passed all tests to prove it.  I store my own coins in Piper and I wouldn't feel safe accepting anything less than that.

[piotr_n]

Unauditable?  Check this tool out: http://www.phy.duke.edu/~rgb/General/dieharder.php

But it is not an audit of the silicon - it is just a test of an entropy of the data that it outputs.

You can design a hardware in a way that it will output a high entropy data, though according to your pattern.
And then, when you know the secret pattern - you can predict what it would generate...

Of course its just a theory, but theorizing is what we do here.
But in any case hardware random number generators are in general unauditable - you don't know what they do and how they do it.
You need to trust the manufacturer and most of them are big corps that should not be trusted, as Google itself has already proven with their SecuredRandom class implementation in Android - I'm old enough to know that you don't usually make such a serious "screw ups" by mistake.

If you build your own hardware and then test it for entropy - such a hardware you can trust.
But usually its just easier and cheaper to trust yourself with picking a random seed-string

[deepceleron]

Unauditable?  Check this tool out: http://www.phy.duke.edu/~rgb/General/dieharder.php

But in any case hardware random number generators are in general unauditable...

Yup, SHA2 of passwords from aaaaa-ZZZZZ will also pass random tests.

[glitch003]

Unauditable?  Check this tool out: http://www.phy.duke.edu/~rgb/General/dieharder.php

But it is not an audit of the silicon - it is just a test of an entropy of the data that it outputs.

Just one minor nitpick.  We're not testing the hardware RNG directly, we're testing the final output of /dev/random when it's being continuously fed entropy from the hardware RNG.  /dev/random has it's own whitening algorithms and doesn't JUST use the entropy provided from the hwrng, it pulls from a number of other places as well. 

I agree with you that using JUST the output from the hwrng is unsafe.  So that's why we feed the entropy into /dev/random and don't use it directly.  Our test is testing the system as a whole.

Your points are certainly valid though.

[glitch003]

Unauditable?  Check this tool out: http://www.phy.duke.edu/~rgb/General/dieharder.php

But in any case hardware random number generators are in general unauditable...

Yup, SHA2 of passwords from aaaaa-ZZZZZ will also pass random tests.

Well of course, the whole point of SHA2 and other cryptographic hash functions is that they are designed to have very strong uniformity guarantees. 

[johnyj]

I still think that dice or coin is the purest random generator, just need to get some high quality dice (maybe some certified casino dice?)