Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When Random Isn't Random Enough: Lessons from an Online Poker Exploit

lauradhamilton.com

Post reply on HN
Print view View original

61–70 of 90 posts

Re: When Random Isn't Random Enough: Lessons from an Online Poker Exploit

#61

Post by MertsA »

sillysaurus2 wrote: post #25
letstryagain wrote: post #24

Earlier quoted context omitted.

The major sites don't do this. We know because many people out there collect literally millions of poker hands observed on these sites and mine the data for every kind of statistic you can think of. If anything significant was out of whack they would have picked it up. Look at the 'online poker' section of the twoplustwo forums for example. The random number generators used by these sites are hardware systems that us…

The random number generators used by these sites are hardware systems that use micro fluctuations in ambient temperature (for example) as a source of entropy and they are very careful to use enough bits of entropy for every card shuffled. It's amusing to realize that they could just read from dev/urandom with zero risk. They're probably not running Linux, but still. So, for anyone who's wondering if you need this, or…

Actually for something cryptographic or sensitive in nature you would want to read from /dev/random. The "u" in urandom stands for unlimited, basically if the entropy pool runs dry, reads from /dev/urandom will still return data but that data doesn't necessarily have a significant amount of entropy in it. Reads from /dev/random however will block and wait for more entropy if the entropy pool runs dry.

Re: When Random Isn't Random Enough: Lessons from an Online Poker Exploit

#62

Post by IanCal »

just2n wrote: post #60
Nilzor wrote: post #58

Earlier quoted context omitted.

"I'm not entirely convinced the off-by-1 is substantial". What? You don't think always putting ace of spades at the bottom of the deck is substantial? (given that's what "52" represents)

That wouldn't be the result. The result is that the final card is swapped only once, and can never be swapped with itself, meaning it is always somewhere else in the deck. If the final card is the ace of spades, then the ace of spades can never be the last card in the shuffled deck. In most casino card games, shuffles happen before this knowledge becomes particularly useful, which is why I don't think it's necessaril…

> Being able to easily guess the seed is, however, a pretty massive issue.

Particularly since they initialise the deck each time (it'd be a massive issue anyway, but this just makes it worse).

Starting with 2^32 states, and knowing their algorithm, you have ~4 billion possible shuffles. However, each card you see drastically reduces the search space. My reasoning is that each card you know reduces the possible number by about how many cards it could have been (so no knowledge is 2^32, one card is 2^32 / 52 ...)

Knowing just one card brings you to one of 83 million possible decks. One more card and you're down to just 1.6 million.

Once the flop is down, you know 5 cards and that means there are only about 15 possible decks.

I think this reasoning is right, but it does seem rather dramatic. I'll have to write a simulation, I've been looking for a good blog post to work through & to work on my visualisations.

Re: When Random Isn't Random Enough: Lessons from an Online Poker Exploit

#63

Post by tptacek »

MertsA wrote: post #61
sillysaurus2 wrote: post #25

Earlier quoted context omitted.

The random number generators used by these sites are hardware systems that use micro fluctuations in ambient temperature (for example) as a source of entropy and they are very careful to use enough bits of entropy for every card shuffled. It's amusing to realize that they could just read from dev/urandom with zero risk. They're probably not running Linux, but still. So, for anyone who's wondering if you need this, or…

Actually for something cryptographic or sensitive in nature you would want to read from /dev/random. The "u" in urandom stands for unlimited, basically if the entropy pool runs dry, reads from /dev/urandom will still return data but that data doesn't necessarily have a significant amount of entropy in it. Reads from /dev/random however will block and wait for more entropy if the entropy pool runs dry.

No, this is an urban myth perpetuated by a broken man page. Cryptographic software should use urandom, not random.

Re: When Random Isn't Random Enough: Lessons from an Online Poker Exploit

#64

Post by sillysaurus2 »

MertsA wrote: post #61
sillysaurus2 wrote: post #25

Earlier quoted context omitted.

The random number generators used by these sites are hardware systems that use micro fluctuations in ambient temperature (for example) as a source of entropy and they are very careful to use enough bits of entropy for every card shuffled. It's amusing to realize that they could just read from dev/urandom with zero risk. They're probably not running Linux, but still. So, for anyone who's wondering if you need this, or…

Actually for something cryptographic or sensitive in nature you would want to read from /dev/random. The "u" in urandom stands for unlimited, basically if the entropy pool runs dry, reads from /dev/urandom will still return data but that data doesn't necessarily have a significant amount of entropy in it. Reads from /dev/random however will block and wait for more entropy if the entropy pool runs dry.

tptacek has addressed this concern many times before: https://hn.algolia.com/?q=author:tptacek%20urandom#!/comment...

The summary is that it's a myth.

Re: When Random Isn't Random Enough: Lessons from an Online Poker Exploit

#65

Post by tptacek »

hueving wrote: post #46
chops wrote: post #31

The solution here, which the article fails to mention, and which every security expert will undoubtedly tell you, is to make sure you use super random numbers (that's the technical term, for the layperson) by adding two random numbers together.

No! You call a blocking rand function bound by available entropy. If your random source is compromised, adding two numbers from the same broken source does nothing. What you can do though, is XOR numbers from independent random sources to improve the entropy of the final output. (not sure if that's what you meant by adding random numbers together)

Oh, I get it. These are both joke comments that are commenting on the weird number of urban legends surrounding randomness.

Re: When Random Isn't Random Enough: Lessons from an Online Poker Exploit

#66

Post by dublinclontarf »

hueving wrote: post #46
chops wrote: post #31

The solution here, which the article fails to mention, and which every security expert will undoubtedly tell you, is to make sure you use super random numbers (that's the technical term, for the layperson) by adding two random numbers together.

No! You call a blocking rand function bound by available entropy. If your random source is compromised, adding two numbers from the same broken source does nothing. What you can do though, is XOR numbers from independent random sources to improve the entropy of the final output. (not sure if that's what you meant by adding random numbers together)

I guarantee you these guys were not using test driven development, they need to TEST that their random number generator is random enough.

With TDD they would never have had these problems.

Re: When Random Isn't Random Enough: Lessons from an Online Poker Exploit

#67

Post by dublinclontarf »

chops wrote: post #57
brazzy wrote: post #48

Earlier quoted context omitted.

I believe that chops was being sarcastic in ascribing a typical naive and useless attempt at "improving" randomness to "experts". Come on, "super random numbers"??

Yes, it was indeed a joke. And one which has apparentlly fallen flat.

No no, I got it, much enjoyed.

Re: When Random Isn't Random Enough: Lessons from an Online Poker Exploit

#68

Post by stephan10h »

Flaw #3 seems flawed to me. There are 52! possible ways to shuffle a deck of cards but a game is only played using a small subset. Suppose there are 4 players, then you need 2 times 4 plus 5 is 13 cards. The remaining deck of 39 cards can be shuffled in 39! ways without affecting the game. These possibilities are still included in those 52! of total possibilities. In case of 4 players there are only 52!/39! possible games that can be played. This is still a larger number then the 4 billion mentioned in the article but it doesn't dwarf the 4 billion as the 8*10^67 does.

Re: When Random Isn't Random Enough: Lessons from an Online Poker Exploit

#69

Post by Ellipsis753 »

wtallis wrote: post #43
Ellipsis753 wrote: post #13

Earlier quoted context omitted.

That's a bad idea. You shouldn't be trusting random.org with your random data (what if they get hacked or something). Also if it's send over http then an attacker could listen in to the random data you were being sent (either at your end or at random.org). Ultimately I think you'd do best to use several software methods and 2 hardware methods and just xor them all together into a single secure source of random number…

> " ...use several software methods and 2 hardware methods and just xor them all together... " An xor is only okay if you ensure that all of your RNGs are completely independent - unable to affect or observe each other, and do not draw any of their input from any shared or correlated sources. If you've got two machines seeding their entropy pools with packet timings from the same network, then XORing their PRNG outpu…

I do however think that I am correct in thinking that provided that any one of your sources is "true" and independent then the xor'd string of binary will be completely random. You cannot xor an unkown random binary string and make it less random.

Re: When Random Isn't Random Enough: Lessons from an Online Poker Exploit

#70

Post by ye »

lutusp wrote: post #16
bloodmoney wrote: post #12

I admit I am a total noob here, but couldn't you make something with a TV turned to a station with just static? I have often wondered about this but lack the 'propriate schoolin'.

In engineering terms, it's easier to use a reversed-biased diode as a noise source. An input circuit would transfer the diode's random waveform into a shift register as zeros and ones, until the desired word size has been assembled. It's really quite simple, and it could produce a very high degree of randomness. It would differ from typical PRNGs in that the binary sequence could not be reproduced, no matter how much…

In engineering terms it would be easier to cover a shitty webcam with a bag, take a photo, and then use the lower bit of each pixel as the source of entropy.

You can use other things, like microphone input, or CPU temperature.

No need to buy expensive hardware generators.

Then you can use something like Fortuna to generate more random numbers from that seed:

http://en.wikipedia.org/wiki/Fortuna_(PRNG)

Post reply on HN