Fairness guarantee in online gambling via Secure Hash Algorithm

I think almost every time I bring up a topic related to Internet gambling EvenBob chimes in to say that they are all rigged to cheat your money.

Perhaps in an effort to address such skepticism, BetVoyager casino offers a way that they say guarantees fairness. It works like this, if I understand it correctly.

1. A 64-digit code is given to the player in the top of the screen before he makes a bet. This is called the "checksum."
2. The player makes his bet and the game plays out.
3. At the conclusion of the game, the player may click a check mark. If he does, he will be taken to a screen showing the predestined outcome or cards in the game.
4. If the player clicks "calculate checksum," then the game will translate the text of the game outcome into a checksum. The player can compare it to the checksum he was given before the game and will see that it matches.

Here are a couple links that explain it in more detail:

Randomness control
Randomness control in roulette video

Personally, I applaud this! While I maintain that most major Internet casinos do not cheat, I always favor open and honest gambling. This is a great step in that direction. Of course, I'm sure there will still be some skeptics.

I also wonder if the hackers out there are trying to figure out how the checksum translator works. If one knew how, he could gamble with perfect knowledge of the outcome. This is getting out of my area, but I suspect they are using semi-prime numbers, which can take orders of magnitude greater than the age of the universe to crack. Then again, if one could hack into the computer of whoever designed this ...

The question for the poll is do you trust this encryption?

If someone could "reverse engineer" SHA-256 like that, making money on online roulette would be the last thing he would be doing with that ability. SHA-256 doesn't appear to use primes, or products of primes (like the key in RSA does), but does a lot of hashing of whatever the input is. I may have to "independently test" the hash result to see if it is a straight SHA-256 hashing.

Description of how SHA-256 works (warning: not for mathophobes)

The only question I have is, in craps, what happens if you have a point established when your current set of rolls runs out? Do you have to request a new set? This could be cumbersome for the player.

Quote: ThatDonGuy

The only question I have is, in craps, what happens if you have a point established when your current set of rolls runs out? Do you have to request a new set? This could be cumbersome for the player.

Good question. I tried this and it seems to me that only the first ten rolls are predestined. I had an 12-roll run but it gave me only the first ten of them:

rolls : 1-3 4, 2-6 2, 3-1 1, 4-4 5, 5-6 4, 6-4 3, 7-5 5, 8-4 4, 9-6 3, 10-6 3; server code word : iSQxNPrK5UZ7L6GrEe9gLOupfuLWeERr

Later...

Upon further playing, it seems like every ten rolls it gives the player a new checksum. The skeptical player can always copy and paste them as he goes and translate them later.

This is going to confuse the average player here so much that they might think the game is trying to deceive you into thinking it's fair!

I think it is a good idea in theory.

However, it can be beaten, by a reverse lookup dictionary. This is the same method used to 'hack' encrypted passwords.

You don't need to decrypt the hashcode. By definition, a hash algorythm isn't reversable, anyway.

You and all of your buddies just record every hashcode and the rolls it represents. If anyone ever encounters a hashcode that has happened before, you clean up.

If anyone figures out or comes by the code to generate the hashcode, you set your computers to work generating hashcodes and recording them and the rolls they represent.

Quote: Dalex64

I think it is a good idea in theory.

However, it can be beaten, by a reverse lookup dictionary. This is the same method used to 'hack' encrypted passwords.

You don't need to decrypt the hashcode. By definition, a hash algorythm isn't reversable, anyway.

You and all of your buddies just record every hashcode and the rolls it represents. If anyone ever encounters a hashcode that has happened before, you clean up.

If anyone figures out or comes by the code to generate the hashcode, you set your computers to work generating hashcodes and recording them and the rolls they represent.

I assume if you win to much they won't pay you. They will say you found a way to hack them.

Couldn't they just reset their code daily, weekly, or whenever they want. Just as you figure out what the codes are,they change.

Quote: Dalex64

I think it is a good idea in theory.

However, it can be beaten, by a reverse lookup dictionary. This is the same method used to 'hack' encrypted passwords.

You don't need to decrypt the hashcode. By definition, a hash algorythm isn't reversable, anyway.

You and all of your buddies just record every hashcode and the rolls it represents. If anyone ever encounters a hashcode that has happened before, you clean up.

If anyone figures out or comes by the code to generate the hashcode, you set your computers to work generating hashcodes and recording them and the rolls they represent.

They always throw in a long series of what look like random characters to create more Checksum combinations. It is such a long sequence that I think it would be unlikely to see the same one twice. Then again, I've been wrong before.

Mike, as you very well know, almost no cheating at Internet casinos arises because of a rigged RNG. That myth is perpetuated by rogue online casinos that boast having their RNG tested, approved, etc. TST and eCogra are happy to do this testing, and I have no doubt that the RNGs are fair. It is all in the programming. So, if the RNG behaves fairly, but the programming that uses the outcomes produced by the RNG is rogue, how does this change anything? Maybe I don't understand.

You quote BetVoyager in your link. From "ThePogg" http://thepogg.com/casino-review/bet-voyager/

Quote:

Bet Voyager use their own proprietary software called GameSys.

That's hardly reassuring. They score a 6/10 on "trustworthiness" on ThePogg. Here is their licensing info, as given on ThePogg:

Quote:

Bet Voyager are licensed by the Curacao Egaming ( http://www.curacao-egaming.com/index-4.html). From a player’s perspective Curacao are wildly seen to be a weak regulatory authority.

This checksum idea seems like fluff. They should have Charles at CFG do the chi-square testing, etc., on their data log files, and have him directly inspect the code, so that they can get properly certified.

Quote: teliot

Mike, as you very well know, almost no cheating at Internet casinos arises because of a rigged RNG. That myth is perpetuated by rogue online casinos that boast having their RNG tested, approved, etc. TST and eCogra are happy to do this testing, and I have no doubt that the RNGs are fair. It is all in the programming. So, if the RNG behaves fairly, but the programming that uses the outcomes produced by the RNG is rogue, how does this change anything? Maybe I don't understand.

You quote BetVoyager in your link. From "ThePogg" http://thepogg.com/casino-review/bet-voyager/


That's hardly reassuring. They score a 6/10 on "trustworthiness" on ThePogg. Here is their licensing info, as given on ThePogg:


This checksum idea seems like fluff. They should have Charles at CFG do the chi-square testing, etc., on their data log files and get properly certified.

The checksum does not gurantee randomness. It just tells you there is no past posting by the casino. But withiut the hashing algorithm being exposed so a player can run it themselves after the results, its meaningless. All we know is that a code was generated that refers to a series of ten results. Not that those ten results generate the checksum.

I would assume to increase the variability of the checksum more data is added to the hash than just the results. Like date and time, for instance.

Quote: thecesspit

It just tells you there is no past posting by the casino. But withiut the hashing algorithm being exposed so a player can run it themselves after the results, its meaningless.

For some games, yes, but not all.

Take roulette for example, past posting is the only way for the casino to cheat. If they rig their outcomes towards certain results before bets, they become exploitable if someone figures it out. And they aren't even guaranteed a profit from their cheating, unless they can predict the player's bets (which may be possible with player history data).

Quote: Dalex64

I think it is a good idea in theory.

However, it can be beaten, by a reverse lookup dictionary. This is the same method used to 'hack' encrypted passwords.

A sequence of 10 dice rolls has one of over 3.65 quadrillion different hash codes. Even if you had a 10-core CPU that could look up 5 billion codes per second, it would take 650 hours.

Quote: ThatDonGuy

A sequence of 10 dice rolls has one of over 3.65 quadrillion different hash codes. Even if you had a 10-core CPU that could look up 5 billion codes per second, it would take 650 hours.

The information going into the hash codes includes a long string of apparently random characters. Here is the code from the craps game I quoted earlier:

iSQxNPrK5UZ7L6GrEe9gLOupfuLWeERr

Lucy showed Charlie Brown a signed document. Charlie Brown was quite excited. "It is! It's a signed document!" Then she yanked the football away, anyway.


They're saying something. We don't know what they're saying.

We should see the source code, we should have some certainty that the running code was compiled from the inspected source code (and works as purported), we should have a clear understanding of what they're saying, and we need to know that they'll pay out.

What can I say... I'm a skeptic.

Quote: ThatDonGuy

A sequence of 10 dice rolls has one of over 3.65 quadrillion different hash codes. Even if you had a 10-core CPU that could look up 5 billion codes per second, it would take 650 hours.

Hmmm, I partly hope there is the flaw you've just pointed out....

Quote: ThatDonGuy

A sequence of 10 dice rolls has one of over 3.65 quadrillion different hash codes. Even if you had a 10-core CPU that could look up 5 billion codes per second, it would take 650 hours.

Storage is the constraint against a rainbow table.

My quick math says that just the indices to the data will be around 292 petabytes (that's 80 bytes per hash, which isn't enough to store the cleartext - just barely enough to store the hashes themselves).

That's 58400 5TB hard drives. Assuming you get a good deal and only pay $20 a piece, that's over a million bucks of drives. You'll also need power supplies and something to run the drives with - probably some servers. You'll probably want them networked. You'll probably need some air conditioning to keep them all from overheating.

Now, if you use an arrangement like storage pods, you can realistically get 450 drives per 42U rack, leaving you 2U for networking equipment. That's 130 racks to put your storage in. I'm figuring about $35k/rack, plus drives.

Call it 6 million* or so, just for storing the index data. You'll need some processing capacity, too.

If you actually want to store meaningful amounts of data, I'd expect to multiply that by about 20.

That's a lot of investment to beat a $5 bet, or even a $100 bet.


*edit: Remember, you got a really good deal on the drives. Multiply the drive cost by 8.

I wonder what the 32-character "server code word" does. Since it uses both uppercase and lowercase letters as well as numbers, I am assuming each character represents 6 bits, using a Base64-style representation, and the whole thing is a 96-bit unsigned integer. Each character could also be a "base 58" value, similar to what Bitcoin uses, but the Bitcoin standard does not include the capital letter O (or digit 0, for that matter - it also leaves out capital I and lowercase L), which is in the text.

If you change the server code word value - or, for that matter, the text "Server Code Word" itself - does the checksum change?

Quote: ThatDonGuy

If you change the server code word value - or, for that matter, the text "Server Code Word" itself - does the checksum change?

If it's a "typical" SHA256, yes. Any change in input data changes the output hash.

I'm not sure exactly what the server code word does, nor how often it is changed. If we assume weekly changes, it would confound anyone who is storing the hashes and plaintexts of past results hoping to land on a replay with perfect foreknowledge. (In this case, replays would almost certainly not happen - almost no chance of them happening within the same week, and if the server code is changed they are extremely unlikely to happen outside the same week.)

While the server code word might have meaning, I expect it's just salt.

Quote: Wizard

I think almost every time I bring up a topic related to Internet gambling EvenBob chimes in to say that they are all rigged to cheat your money.

Perhaps in an effort to address such skepticism, BetVoyager casino offers a way that they say guarantees fairness. It works like this, if I understand it correctly.

1. A 64-digit code is given to the player in the top of the screen before he makes a bet. This is called the "checksum."
2. The player makes his bet and the game plays out.
3. At the conclusion of the game, the player may click a check mark. If he does, he will be taken to a screen showing the predestined outcome or cards in the game.
4. If the player clicks "calculate checksum," then the game will translate the text of the game outcome into a checksum. The player can compare it to the checksum he was given before the game and will see that it matches.

Here are a couple links that explain it in more detail:

Randomness control
Randomness control in roulette video

Personally, I applaud this! While I maintain that most major Internet casinos do not cheat, I always favor open and honest gambling. This is a great step in that direction. Of course, I'm sure there will still be some skeptics.

I also wonder if the hackers out there are trying to figure out how the checksum translator works. If one knew how, he could gamble with perfect knowledge of the outcome. This is getting out of my area, but I suspect they are using semi-prime numbers, which can take orders of magnitude greater than the age of the universe to crack. Then again, if one could hack into the computer of whoever designed this ...

The question for the poll is do you trust this encryption?

Can you give a description what a checksum is and how it and the other stuff works so evryone can understand it? Is there a system out there that guarantees randomness, somthing that can't be manipulated though the backdoor (whatever that means)

Let me explain how most people think when it cimes to online gambling. People believe the software providers or casino creates software that's initially random/fair. It may be checked and tested by a 3rd party.

The casino then find an elaborate way to override that AkA a switch they can turn on and off to cheat player's.

The most common belief is that when a player suddenly bets an amount larger than normal the dealer forces the player to lose. Bet $1 W $1 W $1 W $1L $1 W ($50 Lose allmost evrytime) If you start betting $50 regularly the system detects that and starts allows for a more randomized situation.

Assume you had an online casino what would you do to assure evryone that it was allways 100% Fair and random? Or is this next to impossible?

Quote: AxelWolf

Can you give a description what a checksum is and how it and the other stuff works so evryone can understand it? Is there a system out there that guarantees randomness, somthing that can't be manipulated though the backdoor (whatever that means)

The "quick" version is: a checksum is a function applied to a block of data, which is usually used to verify that what should be two identical blocks of data match. For example, if I am sending a block of data over the Internet, first I will calculate the checksum of the data, then send it, then have the recipient calculate the checksum; if they match, then we should be fairly confident that the data matches, but if the checksums are different, then the data got garbled along the way.

In this case, the app generates a series of random numbers and, apparently, some 32-character "server code", then writes them to text and calculates the checksum on the text. The text is then shown to the player, who can calculate the checksum on his own. If the text is changed in any way - for example, changing one of the random numbers - then the checksum changes as well. If the checksums match, then you can assume that the numbers that were generated in advance are the ones that were used in the bets.

The only problem might be, you are taking the app's word for it when it calculates the checksum of the result text.

The better checksum functions (a) make it almost impossible for two blocks of data to have the same result, and (b) make it almost impossible to be able to calculate the data from the checksum.

SHA-256 is a rather detailed algorithm that involves first padding the data into a multiple of 64 bytes (with a 1 followed by a bunch of zeroes followed by a 64-bit unsigned integer which is the size of the original data in bits), then breaking it up into 32-bit chunks, then, starting with eight 32-bit constants, applying 32 operations to each chunk, resulting in eight 32-bit values (256 bits, which I assume is why it is called SHA-256) which, when combined, become the final checksum.

Quote: AxelWolf

Let me explain how most people think when it cimes to online gambling. People believe the software providers or casino creates software that's initially random/fair. It may be checked and tested by a 3rd party.

The casino then find an elaborate way to override that AkA a switch they can turn on and off to cheat player's.

The most common belief is that when a player suddenly bets an amount larger than normal the dealer forces the player to lose. Bet $1 W $1 W $1 W $1L $1 W ($50 Lose allmost evrytime) If you start betting $50 regularly the system detects that and starts allows for a more randomized situation.

Assume you had an online casino what would you do to assure evryone that it was allways 100% Fair and random? Or is this next to impossible?

As somebody has already posted here, this isn't intended to validate the randomness of the numbers; it just lets you make sure that the numbers were generated before you made the bet. Then again, The Wizard said that he was in the middle of a point when the app generated a new set of numbers, so it's possible that these numbers could have been rigged to affect the point in progress (for example, have a 7 show up if the player is betting with the point, or have the point show up if betting against it).

The server code has to change on a regular basis, presumably after every generation of a hash code, and can't be known a-priori to the user.

If it is static for any period of time, there is a huge hole in the procedure, from what I can tell.

Quote: ThatDonGuy

I wonder what the 32-character "server code word" does. Since it uses both uppercase and lowercase letters as well as numbers, I am assuming each character represents 6 bits, using a Base64-style representation, and the whole thing is a 96-bit unsigned integer. Each character could also be a "base 58" value, similar to what Bitcoin uses, but the Bitcoin standard does not include the capital letter O (or digit 0, for that matter - it also leaves out capital I and lowercase L), which is in the text.

If you change the server code word value - or, for that matter, the text "Server Code Word" itself - does the checksum change?

I ran one spin, and ran the complete checksum output text through my own SHA-256 hash calculator, and it matched the checksum that the app generated. This means that both the numbers and the server-generated code word are part of the hash, so unless you know the code word in advance, even being able to lookup hash values won't help you determine what the numbers are going to be.

Since the numbers and the code word have to be generated in advance in order for the checksum to be displayed before the random numbers are used, I vote for "secure."

Quote: ThatDonGuy

I ran one spin, and ran the complete checksum output text through my own SHA-256 hash calculator, and it matched the checksum that the app generated. This means that both the numbers and the server-generated code word are part of the hash, so unless you know the code word in advance, even being able to lookup hash values won't help you determine what the numbers are going to be.

Since the numbers and the code word have to be generated in advance in order for the checksum to be displayed before the random numbers are used, I vote for "secure."

I assume the code word changed each time as well.

It has to, as it's not a hash look up you'd need to do on all 10 spins. You'd generate 9, then generate the 37 possible hashes for the last spin. You'd find a match, then bet big on the tenth spin.

That would easily get you an advantage... until they realized what you were doing....

Quote: thecesspit

I assume the code word changed each time as well.

It has to, as it's not a hash look up you'd need to do on all 10 spins. You'd generate 9, then generate the 37 possible hashes for the last spin. You'd find a match, then bet big on the tenth spin.

That would easily get you an advantage... until they realized what you were doing....

In fact, you can limit the checksum calculation to just one spin, so the code word had better change each time. This would also explain the necessity of a code word in the first place - without it, there would be one checksum value for each of the 38 numbers, so eventually the app would be telling you the next number every time.

It would be better if the hash-code was also changed every X hands, randomly within a range (say 2 to 31).

IMHO all of this is for naught when using JAVA as the WAN interface. Very hackable. Active-X is about the only thing worse.
Further, using SSH ports are not as good as SSL ports. Note the poker room stories aluded to earlier in the thread, these are the former. /IMHO

In the ten years since I last played poker on-line, there have been some security flaws fixed for the end-user and for server hosts and clients. One must wonder how many of these flaws are repaired in the House of Gaming. For example the use of SSL3 is a total waste of money, as its hackable/deniable. Most Operators would need SHA256/TLS1.2 as a base for safer gaming.

ThatDonGuy explains the hash codes well. I use it in Linux to verify ANY download. If an Author creates a file, the original version has an MD5 (one type of checksum) code that s/he puts in a text file separately or posts for the public. When I download that file, my checksum must match the Author's to be valid.

Looking at the demo videos shows the text they are hashing has relatively little practical data and a large server string (salt). This sort of text is the best case situation for generating hash collisions. I am not sure how collision resistant SHA-256 is but an apparently random large salt and the birthday principle, probably put it in the range of possibility. A dishonest operator could exploit this by pre-generating and storing a large number of hash values for different outcomes and server strings. When a collision is found the plain text and hash would be saved for use in the software. Normally the software would generate a random sequence and hash value, but when the casino wanted a sure win, they would use the stored hash value and decide the sequence after you have bet. Now I don't think it is likely to add the hash only to add a workaround, but it is possible.

Quote: someone

Looking at the demo videos shows the text they are hashing has relatively little practical data and a large server string (salt). This sort of text is the best case situation for generating hash collisions. I am not sure how collision resistant SHA-256 is but an apparently random large salt and the birthday principle, probably put it in the range of possibility. A dishonest operator could exploit this by pre-generating and storing a large number of hash values for different outcomes and server strings. When a collision is found the plain text and hash would be saved for use in the software. Normally the software would generate a random sequence and hash value, but when the casino wanted a sure win, they would use the stored hash value and decide the sequence after you have bet. Now I don't think it is likely to add the hash only to add a workaround, but it is possible.

First, the hash is displayed before your first bet - otherwise, it defeats the whole purpose, as the numbers and the seed could be generated after the bet and then the hash displayed. Pretty much the entire point of SHA256 is to make hash collisions virtually impossible; there are 34 bytes (10 for the numbers drawn, plus 24 for the hash key (did I say 96-bit integer earlier? I meant 192)) that are hashed.

Second, even if duplicates were found, the "selected" set would only be to the casino's favor for the first number; the casino is then stuck with the remaining nine numbers from that set. True, that does give the casino an advantage on 10% of the bets, but if it worries you that much, make your first bet out of every 10 small.

Don,
I don't think that it is a practical threat of an online casino adding the hash just to go to the effort of calculating a hash collision, but it theoretically is possible. Searching a bit more I believe that SHA256 is effectively collision proof for the moment at the financial level that online casinos could consider.