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.

[1714717817]

1714717817

[1714717817]

1714717817

[1714717817]

1714717817

[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?)

[CIYAM]

Can you sign transactions offline with Bitcoin-Qt?

Yes of course you can - it's called "signrawtransaction" (I use it with the CIYAM Safe which is a 100% air-gapped offline tx signing system).

[go1111111]

Can you sign transactions offline with Bitcoin-Qt?

You can using the command line, but it's cumbersome: https://people.xiph.org/~greg/signdemo.txt

[keystroke]

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?

It should be possible with the API. Then just use sendrawtransaction with the online client.

[coastermonger]

How do you think the "input mouse movement" for bitaddress.org stacks up for randomness?

[deepceleron]

How do you think the "input mouse movement" for bitaddress.org stacks up for randomness?

I just have a guess, do you have one?

<script type="text/javascript">
ninja.seeder = {
   // number of mouse movements to wait for
   seedLimit: (function () {
      var num = Crypto.util.randomBytes(12)[11];
      return 50 + Math.floor(num);
   })(),

   seedCount: 0, // counter

   // seed function exists to wait for mouse movement to add more entropy before generating an address
   seed: function (evt) {
      if (!evt) var evt = window.event;

      // seed a bunch (minimum seedLimit) of times based on mouse moves
      SecureRandom.seedTime();
      // seed mouse position X and Y
      if (evt) SecureRandom.seedInt((evt.clientX * evt.clientY));

      ninja.seeder.seedCount++;
      // seeding is over now we generate and display the address
      if (ninja.seeder.seedCount == ninja.seeder.seedLimit) {
         ninja.wallets.singlewallet.open();
         // UI
         document.getElementById("generate").style.display = "none";
         document.getElementById("menu").style.visibility = "visible";
      }
   },

   // If user has not moved the mouse or if they are on a mobile device
   // we will force the generation after a random period of time.
   forceGenerate: function () {
      // if the mouse has not moved enough
      if (ninja.seeder.seedCount < ninja.seeder.seedLimit) {
         SecureRandom.seedTime();
         ninja.seeder.seedCount = ninja.seeder.seedLimit - 1;
         ninja.seeder.seed();
      }
   }
};


How does it "stack up", I guess that depends on how secure you find seeding RC4 with some mouse positions.

[piotr_n]

I found this news somehow relevant to the discussion we had at the previous page, so I will post it here.

“We cannot trust” Intel and Via’s chip-based crypto, FreeBSD developers say

Developers of the FreeBSD operating system will no longer allow users to trust processors manufactured by Intel and Via Technologies as the sole source of random numbers needed to generate cryptographic keys that can't easily be cracked by government spies and other adversaries.

The change, which will be effective in the upcoming FreeBSD version 10.0, comes three months after secret documents leaked by former National Security Agency (NSA) subcontractor Edward Snowden said the US spy agency was able to decode vast swaths of the Internet's encrypted traffic. Among other ways, The New York Times, Pro Publica, and The Guardian reported in September, the NSA and its British counterpart defeat encryption technologies by working with chipmakers to insert backdoors, or cryptographic weaknesses, in their products.

more: http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/

[Jace]

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

Same here, I am extremely paranoia about this.

Almost 100% secure: just create them as brainwallets from very long random input strings. Obviously you don't need to remember these, they're meant for cold storage so they're not actual 'brainwallets'. They're just created in the same way as brainwallets, i.e. the private keys are hashes from strings. This rules out any dependency from random generators with possible weaknesses.

When I say 'very long random input strings', I mean garbage like this: (just typing a bunch of gibberish characters)

Code:

fY72^og(fU FO!MNxTL/rwA q2kd#plv0ni40X.e4 7n7*4nv5^3u 2_14h D!IQZD6k3L7n

For this particular example, the private key would be Sha256("fY72^og(fU FO!MNxTL/rwA q2kd#plv0ni40X.e4 7n7*4nv5^3u 2_14h D!IQZD6k3L7n") = eab9498f0c866509a2ff09fa40b556776f54b78f941f36cc69bdbf7832f45473, or expressed in more common Bitcoin format: 5KbfHWM9R2AKhoAtkcTDv6agnzJoPCHZkrEnSy8t8bnVTUHJnND and its corresponding address is 1FtUbMx47zhF3AUWTWCULQzDyRJgVDV23G.

Now, to compensate that last bit of paranoia (and just in case some day an entropy weakness is discovered in Sha256 or something), I took this one step further, and created the private keys for my 'big savings' addresses as three xorred hashes:
(1) Some generated (pseudo?)random private key (using bitcoind or bitaddress.org or whatever)
(2) The Sha256 hash of some long random garbage string
(3) The Sha3-256 hash of some different long random garbage string

So for example:
(1) = 5K2F4Ng3ZYx9s98yEj1ukm1boGEHrAt5rMxXy2cnRdMuQtgTVE7 = 9ed845749f418efc834f1b9b5fd0c1765e7ace2177153a59dc818d6ac5df6232
(2) = Sha256("wP7fB2-fo#90wZ7d 4p6.Z1Ug5r H!0tI6*gp7!zcn)V bw4!Qib") = 7220f93d3a8059d19a3a1be4a2e1c3294185ffcae61aece0d02d73d43f9840d2
(3) = Sha3-256("v5!0ZF%kv 2p0isI*yWJ dky3R7Q#en!4X6;UGS-v35r U#aw/5{61ca") = b6783aadb56f8228feb9673eaf15184417ecc3a1e854ed75bf26de1b126c1c26

Xorring these three gives 5a8086e410ae5505e7cc674152241a1b0813f24a795b3bccb38a20a5e82b3ec6 which results in 5JW9LPbpY1b8aLd8MHkZBCtSCbmA29oaHA1jmpf5dWAEntfYo58 / 13wCBWBnQ86kKHBztMm3j44wb53RYP8LuQ.

I'm quite convinced it doesn't get any more secure than this, in terms of private key 'randomness'.

[dre_2ooo]

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

Same here, I am extremely paranoia about this.

Almost 100% secure: just create them as brainwallets from very long random input strings. Obviously you don't need to remember these, they're meant for cold storage so they're not actual 'brainwallets'. They're just created in the same way as brainwallets, i.e. the private keys are hashes from strings. This rules out any dependency from random generators with possible weaknesses.

When I say 'very long random input strings', I mean garbage like this: (just typing a bunch of gibberish characters)

Code:

fY72^og(fU FO!MNxTL/rwA q2kd#plv0ni40X.e4 7n7*4nv5^3u 2_14h D!IQZD6k3L7n

For this particular example, the private key would be Sha256("fY72^og(fU FO!MNxTL/rwA q2kd#plv0ni40X.e4 7n7*4nv5^3u 2_14h D!IQZD6k3L7n") = eab9498f0c866509a2ff09fa40b556776f54b78f941f36cc69bdbf7832f45473, or expressed in more common Bitcoin format: 5KbfHWM9R2AKhoAtkcTDv6agnzJoPCHZkrEnSy8t8bnVTUHJnND and its corresponding address is 1FtUbMx47zhF3AUWTWCULQzDyRJgVDV23G.

Now, to compensate that last bit of paranoia (and just in case some day an entropy weakness is discovered in Sha256 or something), I took this one step further, and created the private keys for my 'big savings' addresses as three xorred hashes:
(1) Some generated (pseudo?)random private key (using bitcoind or bitaddress.org or whatever)
(2) The Sha256 hash of some long random garbage string
(3) The Sha3-256 hash of some different long random garbage string

So for example:
(1) = 5K2F4Ng3ZYx9s98yEj1ukm1boGEHrAt5rMxXy2cnRdMuQtgTVE7 = 9ed845749f418efc834f1b9b5fd0c1765e7ace2177153a59dc818d6ac5df6232
(2) = Sha256("wP7fB2-fo#90wZ7d 4p6.Z1Ug5r H!0tI6*gp7!zcn)V bw4!Qib") = 7220f93d3a8059d19a3a1be4a2e1c3294185ffcae61aece0d02d73d43f9840d2
(3) = Sha3-256("v5!0ZF%kv 2p0isI*yWJ dky3R7Q#en!4X6;UGS-v35r U#aw/5{61ca") = b6783aadb56f8228feb9673eaf15184417ecc3a1e854ed75bf26de1b126c1c26

Xorring these three gives 5a8086e410ae5505e7cc674152241a1b0813f24a795b3bccb38a20a5e82b3ec6 which results in 5JW9LPbpY1b8aLd8MHkZBCtSCbmA29oaHA1jmpf5dWAEntfYo58 / 13wCBWBnQ86kKHBztMm3j44wb53RYP8LuQ.

I'm quite convinced it doesn't get any more secure than this, in terms of private key 'randomness'.

How long would you say the random garbage string needs to be?  100 char?  200?

This intuitively seems more secure than 100 rolls of dice since that would make a string of numbers, whereas these garbage strings are full of numbers, letters, characters, and spaces. 

Do you just make a new text document, mash your keyboard, then copy/paste the string into a brain wallet in bitaddress?  Assuming this is all done on a computer that will never and has never seen the internet and on wired peripherals, of course.

[dunand]

I made a python script to generate a private key using anything you have under your hand to generate randomness. You can use a coin, a dice, bingo balls... At the beginning you choose the base you want to use. The script will ask you to pick numbers until you have the most secure private key possible.

https://github.com/dunand/bingowallet