jm + randomness   9

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 
6 weeks ago 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:
random  randomness  urandom  uuids  tptacek  hackernews  prng 
november 2015 by jm
murbul comments on The security issue of'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 With their custom SecureRandom, this is safe because it mixes the entropy using XOR, so even if the 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
And the final mistake: They were using HTTP instead of HTTPS to make the webservice call to On Jan 4, started enforcing HTTPS and returning a 301 Permanently Moved error for HTTP - see 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  bitcoin  http  randomness  entropy  error-checking 
may 2015 by jm
FreeBSD breaks its kernel RNG for 4 months
If you are running a current kernel r273872 or later, please upgrade
your kernel to r278907 or later immediately and regenerate keys.
I discovered an issue where the new framework code was not calling
randomdev_init_reader, which means that read_random(9) was not returning
good random data. This means most/all keys generated may be predictable and must be
crypto  freebsd  security  lols  rng  randomness  bsd 
february 2015 by jm
Riding with the Stars: Passenger Privacy in the NYC Taxicab Dataset
A practical demo of "differential privacy" -- allowing public data dumps to happen without leaking privacy, using Laplace noise addition
differential-privacy  privacy  leaks  public-data  open-data  data  nyc  taxis  laplace  noise  randomness 
september 2014 by jm
RSA warns developers not to use RSA products
In case you're missing the story here, Dual_EC_DRBG (which I wrote about yesterday) is the random number generator voted most likely to be backdoored by the NSA. The story here is that -- despite many valid concerns about this generator -- RSA went ahead and made it the default generator used for all cryptography in its flagship cryptography library. The implications for RSA and RSA-based products are staggering. In a modestly bad but by no means worst case, the NSA may be able to intercept SSL/TLS connections made by products implemented with BSafe.
bsafe  rsa  crypto  backdoors  nsa  security  dual_ec_drbg  rngs  randomness 
september 2013 by jm

Copy this bookmark: