I doubt whether good PSRNGs, correctly implemented and used, have such a low entropy. However, the probability of coding errors makes the project more plausible.
Trollfi has no understanding of the issue of poor PSRNGs, and is quoting this Hyena person that is making a completely spurious and ridiculous claim. Troll quoting a troll in order to troll.
Can you read?
The issue with poor PSRNGs has noting to do with address generation, the only way poor randomness could be exploited with addresses is if you could reproduce the poor randomness yourself.
The issue is that poor PSRNGs conceivably could reuse or have insufficient entropy in "R" values in signing transactions,
The BCI buggy code was posted for a few hours and affected
both private keys and k (R) values generated during that interval. It was first discovered by someone who was monitoring the blockchain for repeated R values. These repeated Rs exposed some keys that were generated before the bug. Once the problem was diagnosed, people reproduced the buggy RNG and recovered private keys that were either generated during the interval or used as inputs in transactions during that interval. Most, but not all, of the compromised keys were of the latter type.
that pedantic P(security broken) formula
It is the sad problem with all security mechanisms, not just computer security.
Two years ago the
Brazilian Election Board held a public challenge to demonstrate the security of their ridiculous electronic voting machine. They stacked the rules as much as they could: entrants could only look at the code (~1 million lines of C) for a few hours during 2 days, could not copy it, had a few more hours to describe their attack and its goals, etc.. Even so, a young prof from my dept took the challenge, more for the fun than with the hope of succeding.
At the end of each election, the machine prints a scrambled list of all the votes cast (don't ask why). The permutation was randomly chosen so that the votes could not be associated to voters. My colleague noticed that, while the scrambling itself was properly done, it used an old RNG from the Linux library that the manpage itself said was deprecated. The sequence of numbers generated by that RNG had only 16 bits of entropy (the seed), so my colleague quickly wrote a program that just enumerated the 65k possible seeds, reproduced the scrambling, and used some redundancy of the list to check them. The hardest part was typing the 400+ items of the scrambled list. Once the correct seed was identified, he could recover the original order of the votes and hence the precise time at which each vote was cast.
At that point he still had some time left, so he looked again at the code, and found that the seed was actually the timestamp of the moment when the machine was booted -- which the machine printed at the top of the report.
Moral: that P formula is very important, because it takes into account the stupidity and arrogance of the security experts who implement those ultra-cally-hyper-secure cryptographic methods, and of the users who trust any code that they downloaded from the net since it was vouched for by Antonopoulos or Roger Ver.
Poll
