Quote from: Rampion on October 14, 2014, 08:29:03 AM

Alan, what do you think of "Hash Hyena" claims?

He basically says that he is generating trillions of addresses non stop and getting a few collissions that will grow over time. His logic is that the entropy of Armory, Bitcoin Core, Multibut, Electrum etc. (and generally any other wallet that uses a RNG based on software) is flawed and results in a highly reduced keyspace, which will result in collissions with enought computing power and space devoted to private keys bruteforcing.

See: https://bitcointalk.org/index.php?action=profile;u=380718;sa=showPosts

What is your position on that? I remember that Dabs (I think) requested a feature in order to input "true entropy" from a physical source (a decks of cards, dices, etc.) - how's the progress on that? It might be a good thing to mitigate software RNG issues, but I assume it might be difficult because an unssavy user might make entropy worse by not using "true entropy" right.

If those apps are using truly poor RNGs, then I suppose it's possible. But it would have to be pretty bad to be getting collisions within trillions of addresses +/- a few orders of magnitude. Address strings are 160 bits. So a collision means that two different public keys produce the same address. If you want to "collide" with someone else, i.e. get an address string that matches someone else who has coins, it will take you approx 2¹⁶⁰/numberOfUsers. Even if we assume a trillion users&addresses (2⁴⁰), that's still 120 bits left which is within range of universally secure (128 bits).

Now, if he wants to generate gajillions of addresses and find collisions within any two of them, that's remarkably easier, but also remarkably less useful. The idea being that he wants any two public keys that have the same hash. i.e. generate addresses until you have two that match. Not useful, since you're guaranteed to collide with an address that has no money, but it would still be interesting.

In such cases, if the number scales with approx sqrt(N). i.e. if you are generating 160-bit values, there's 2¹⁶⁰ possibilities. You need to generate approximately sqrt(2¹⁶⁰)=2⁸⁰=1,208,925,819,614,629,174,706,176 to have a single collision. That's a trillion trillion... while that might actually be possible with an extrardinary amount of computing power (in the future), you're still generating collisions that don't benefit you.

Scale all this by the quality of the RNG -- if the RNG is weaker, the state is reduced. Technically, if the hash160 (ripemd160) is weak, the address space could be smaller too. But I would have a tough time believing that desktop apps would not be producing enough entropy, as long as they are using a good RNG.

On that note, Armory uses Crypto++ was is considered a cryptographically-secure RNG (X9.17 with OS-provided seeding). On top of that, Armory pulls in system files, mouse clicks, keypresses, and a desktop screenshot, to add to the Crypto++ RNG entropy pool. I made sure when selecting these sources that it would guarantee at least 256 bits of entropy to be added to the pool even if Crypto++ was really weak.

You're right about the external entropy: we don't provide an option for users to add their own entropy for the reason you described (it becomes a channel for creating brainwallets, too). However, we do it ourselves because it's pretty simple with a deck of cards and a python shell with armoryengine loaded. I've posted elsewhere how to do this, but I don't say it a lot because I don't want it too easy to find out

Primarily because I'm 200% comfortable with Cryptopp + external entropy, so I don't feel there's any practical reason to prefer that beside enjoying "seeing" the entropy yourself.