Crowex: Nice! I like that.

gmaxwell: I see what you are saying. I just wish there was a nice tool (gui or command line) to easily generate multi-sig transactions. AFAIK there isn't.

What do you guys think about the algorithm in my original post? Is there anything else bad beyond the need to put all parts in one place on spend time?

I am not saying Armory isn't secure. I am saying the security of Armory == the security of the underlying /dev/random. Which is not terribly bad, but not terribly good either if you are paranoid as me.

Here is a possible attack on Armory. I sell you a laptop. I think you might install Armory on it. I subvert /dev/random to generate bad random numbers (an extreme way would be to point /dev/random to /dev/zero, but I would probably do something way less obvious). You get the laptop and install Armory (you even verify the signature after downloading!). You fund your wallet. I search through the much smaller key space and steal your funds. The laptop could have been offline the whole time. And it did not matter that Armory needed only 32 bytes. (Of course, if you reinstall the OS my attack would not work. I am counting that you won't).

FIPS assumes that you have a secure entropy source. What FIPS really does is specify algorithms that could stretch an original short random seed into a long stream of pseudo-randomness. But if the entropy source is not secure the assumption is invalidated and FIPS will be broken.

Is there a way to use my own entropy (cards, cubes) with Armory? I didn't see this feature.

Yes but don't multi-sig or secret sharing suffer from the same problem? I still need to collect all the parts in one place when I want to spend my coins.

The generating of the private key and the recombining will all be done on an offline computer. I could just keep one key on the offline computer, but if its stolen I'm screwed, whereas 2-out-of-3 gives me backup.

Thanks. I am actually aware of all these tools. However I am looking for something simple that can be implemented in a shell script and I know exactly how it works. A minimal solution with as few points of failure as possible.

I know I can. Please read my post again. I am trying to avoid raw transactions and complex tools.

I read the crypto++ code and read the docs. From what I saw, AutoSeededX917RNG is seeded from /dev/random or /dev/urandom and then it uses a block cipher (AES) to generate subsequent numbers. There is no other entropy source. Also the docs don't mention other entropy sources. Please point me to the place in the code if I am wrong.

Moreover, it looks like AutoSeededX917RNG is only seeded once, and Armory maintains only a single instance of it. That means that if I am creating multiple wallets in Armory without closing and restarting, all the wallets will be created from the same underlying 256 bits of entropy that were generated on startup. This looks like a problem to me, because I would expect that if I am creating 3 wallets Armory would use 768 bits of entropy and not only 256. Again please correct me if I am wrong.

Regarding /dev/random. I know how it is implemented in linux. I too *think* it is secure. But I am not sure. In principle it is possible that the entropy estimator might miss and overestimate. Or a bug could creep into the debiasing and whiting algorithms in future kernel versions. Such bugs have been known to lay dormant for years. The implications for Armory could be catastrophic. Not saying it is likely, just saying its possible. And I would not recommend the use of Armory on platforms where the quality of /dev/random is more questionable.

Also, note that Armory is meant to be used in offline systems. Such systems obviously have less entropy derived from packet timing. So all else being equal I would expect /dev/random to be slightly weaker when used on an offline computer. That means Armory needs to be even more careful when creating a cold wallet.

In the bottom line, I think Armory should follow TrueCrypt and bitaddress and use /dev/random but only in addition to other entropy sources. It can never hurt. Sure, I would rely on /dev/random to generate a session key for shopping on ebay. But relying solely on it to generate a long term deterministic bitcoin wallet makes my stomach ache.

I am looking for a simple way to generate a private key made out of 3 parts, such that any 2 parts are enough to reconstruct the key.

This is what I came up with:

a = random 256 bit number
b = random 256 bit number
c = a xor b

And now:

private key = sha256(sha256(a) xor sha256(b) xor sha256(c))
public address = bitcoin_address(private key)

I will fund the address and keep a, b and c in three separate physical locations.

In my opinion, the benefit of using this method over multi-sig transactions or secret sharing schemes is that it is much simpler. It can be done in a shell script with common sha256 and xor utilities. No need to write multi-sig transactions by hand or use specialized tools. Of course it is slightly less flexible - its not clear how to emulate 2-out-of-4 multi-sig for example, but 2-out-of-3 is sufficient for me.

What do you think? Is there some security issue I am overlooking?

I am looking at Armory's code to see how the wallet secret key is generated. This is what I saw so far:

PyBtcWallet -> SecureBinaryData -> (Crypto++) AutoSeededX917RNG -> ... bunch of code ... -> /dev/urandom

Now, I don't want to go into the discussion about /dev/random vs. /dev/urandom. The problem is that for bitcoin holding purposes, I actually don't trust /dev/random nor /dev/urandom. It might happen that their implementation in my kernel is silently broken (see Android's case). Or that my machine happens to be low on entropy just as I am about to create a wallet. Since Armory is all about deterministic wallets created with a single master key, it is super-important that this key is generated properly. Randomness in Armory is mission critical. Bad randomness could sweep cold storage coins behind my back.

I am proposing that Armory will use it's own random number generator. Preferably something similar to TrueCrypt's RNG (http://www.truecrypt.org/docs/random-number-generator#Y266). /dev/(u)random, time measurements and mouse movements will be continuously mixed into an entropy pool. Random numbers can then extracted from the pool. When creating a new wallet, Armory will mix mouse movements into the pool for at least 10 seconds before generating the master key. Even bitaddress does this.

I actually really like all the features in Armory - cold storage/offline transactions, deterministic wallets, N-out-of-M backups, etc. But it really saddens me to see its most critical security feature broken like this. I would love to use Armory for storing my coins. But the not-good-enough RNG makes me eery.