jm + prng   6

St. Petersburg team operated a PRNG hack against Vegas slots
According to Willy Allison, a Las Vegas–based casino security consultant who has been tracking the Russian scam for years, the operatives use their phones to record about two dozen spins on a game they aim to cheat. They upload that footage to a technical staff in St. Petersburg, who analyze the video and calculate the machine’s pattern based on what they know about the model’s pseudorandom number generator. Finally, the St. Petersburg team transmits a list of timing markers to a custom app on the operative’s phone; those markers cause the handset to vibrate roughly 0.25 seconds before the operative should press the spin button.

“The normal reaction time for a human is about a quarter of a second, which is why they do that,” says Allison, who is also the founder of the annual World Game Protection Conference. The timed spins are not always successful, but they result in far more payouts than a machine normally awards: Individual scammers typically win more than $10,000 per day. (Allison notes that those operatives try to keep their winnings on each machine to less than $1,000, to avoid arousing suspicion.) A four-person team working multiple casinos can earn upwards of $250,000 in a single week.
prng  hacking  security  exploits  randomness  gambling  las-vegas  casinos  slot-machines 
february 2017 by jm
Neutered RNG let man rig million dollar lotteries | Ars Technica
A forensic examination found that the generator had code that was installed after the machine had been audited by a security firm that directed the generator not to produce random numbers on three particular days of the year if two other conditions were met. Numbers on those days would be drawn by an algorithm that Tipton could predict [...] All six prizes linked to Tipton were drawn on either Nov. 23 or Dec. 29 between 2005 and 2011.
prng  randomness  security  hacks  exploits  lottery  us  audits  holes 
april 2016 by jm
US Lottery insider accused of stealing millions by hacking lottery machines across the US
Prosecutors believe that Tipton, 52, used his access to the machines to surreptitiously install software programs that let him know the winning numbers in advance before disappearing without a trace. They say he worked with associates such as his brother Tommy Tipton — a Texas judge — and Texas businessman Robert Rhodes to play those numbers and collect prizes dating back to 2005.
us  lotteries  prng  randomness  exploits  hacking  insider-attacks  lottery 
january 2016 by jm
Just use /dev/urandom to generate random numbers
Using SHA-1 [to generate random numbers] in this way, with a random seed and a counter, is just building a (perfectly sound) CSPRNG with, I believe, an 80-bit security level. If you trust the source of the random seed, e.g. /dev/urandom, you may as well just use /dev/urandom itself. If you don't, you're already in trouble.

And if you somehow need a userspace PRNG, the usual advice about not rolling your own crypto unless you know what you're doing applies. (Especially for database IDs, the risk of collisions should be considered a security problem, ergo this should be considered crypto, until proven otherwise.) In this case, using BLAKE2 instead of SHA-1 would get you a higher security level and faster hashing.

Or, in tptacek's words: http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
random  randomness  urandom  uuids  tptacek  hackernews  prng 
november 2015 by jm
murbul comments on The security issue of Blockchain.info's Android Wallet is not about system's entropy. It's their own BUGs on PRNG again!
I was in the middle of writing a breakdown of what went wrong, but you've beat me to it.
Basically, they have a LinuxSecureRandom class that's supposed to override the standard SecureRandom. This class reads from /dev/urandom and should provide cryptographically secure random values.
They also seed the generator using SecureRandom#setSeed with data pulled from random.org. With their custom SecureRandom, this is safe because it mixes the entropy using XOR, so even if the random.org data is dodgy it won't reduce security. It's just an added bonus.
BUT! On some devices under some circumstances, the LinuxSecureRandom class doesn't get registered. This is likely because /dev/urandom doesn't exist or can't be accessed for some reason. Instead of screaming bloody murder like any sensible implementation would, they just ignore that and fall back to using the standard SecureRandom.
If the above happens, there's a problem because the default implementation of SecureRandom#setSeed doesn't mix. If you set the seed, it replaces the entropy entirely. So now the entropy is coming solely from random.org.
And the final mistake: They were using HTTP instead of HTTPS to make the webservice call to random.org. On Jan 4, random.org started enforcing HTTPS and returning a 301 Permanently Moved error for HTTP - see https://www.random.org/news/. So since that date, the entropy has actually been the error message (turned into bytes) instead of the expected 256-bit number. Using that seed, SecureRandom will generate the private key for address 1Bn9ReEocMG1WEW1qYjuDrdFzEFFDCq43F 100% of the time. Ouch. This is around the time that address first appears, so the timeline matches.
I haven't had a thorough look at what they've replaced it with in the latest version, but initial impressions are that it's not ideal. Not disastrous, but not good.


Always check return values; always check HTTP status codes.
bugs  android  fail  securerandom  random  prng  blockchain.info  bitcoin  http  randomness  entropy  error-checking 
may 2015 by jm
Randomly Failed! The State of Randomness in Current Java Implementations
This would appear to be the paper which sparked off the drama around BitCoin thefts from wallets generated on Android devices:

The SecureRandom PRNG is the primary source of randomness for Java and is used e.g., by cryptographic operations. This underlines its importance regarding security. Some of fallback solutions of the investigated implementations [are] revealed to be weak and predictable or capable of being influenced. Very alarming are the defects found in Apache Harmony, since it is partly used by Android.


More on the BitCoin drama: https://bitcointalk.org/index.php?topic=271486.40 , http://bitcoin.org/en/alert/2013-08-11-android
android  java  prng  random  security  bugs  apache-harmony  apache  crypto  bitcoin  papers 
august 2013 by jm

Copy this bookmark:



description:


tags: