Quote from: vernell on March 13, 2014, 05:46:50 AM

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.

Perhaps I misread their comments about it. Perhaps the different sources I was thinking about were the list of things it does differently on each OS.

Bear in mind that creating the wallet seed only requires 32 bytes of real randomness. Even an offline computer will have no problem with 32-bytes, and that's far in excess of the really-actually 16 bytes that is considered secure. This isn't RSA where you have to do a search through a large number of random might-be-primes.

I agree it wouldn't hurt to add extra entropy sources, but I think it's quite a stretch to call it insecure. This is FIPS standard for generating random numbers for cryptographic purposes (but, I know you're talking about the seeding instead of the algorithm). When we make an Android app, we absolutely will be supplementing the entropy sources since we have a plethora of entropy sources such as audio and video. For now, I've been recommending that if people are paranoid, they can actually use dice or a deck of cards to do their own entropy.