I have a system that needs to send a key to the user. This key is used for validation after work and needs to be shown that we do not change it mid-work so we send to the user in the middle of work a hash using SHA256 and after the work is done we send the real key and the hashed key so he could check if the key was the same.

The original key is a string made of 32 hexadecimal numbers between 0x00 and 0xff so keys are like this:

key:        6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b
hashed_key: e0bc614e4fd035a488619799853b075143deea596c477b8dc077e309c0fe42e9

key:        d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35
hashed_key: d8bdf9a0cb27a193a1127de2924b6e5a9e4c2d3b3fe42e935e160c011f3df1fc

This will need a maximum of 2 * 10^77 hashes to crack using brute force and it is unlikely someone has enough HD space to create a database for all possible keys

The key we build is probably a hash of something else, for instance in the examples they are hashes to 1 and 2 respectively but they could be for any other string, we use some complex and random numbers (true random) to generate new secure hashes that are very unlikely to repeat.

What would happen if we keep on applying SHA256 over and over? at some point it would circle around?

And given we have a fixed length key to be hashed, would be easier to break? Is there any other method more efficient for this than brute force?

This system works with money (gambling) and we had some problems with "lucky streaks" so I'm trying to understand was it really luck? or someone cracked our system?

EDIT cpast clarification

Computers can't build actual random sequences, given you have the initial values you could recreate any sequence, this is what we use to ensure provability. Every user have at all times 3 server keys and 2 client keys:

  • server keys
    1. the old key, used on previous run, revealed and presented alongside with equivalent hash
    2. the current key, used on current run, concealed and only hash presented
    3. the next key, used on next run, concealed and only hash presented
  • client keys
    1. the old key, used on previous run
    2. the current key, being used

In any given run the winning number is found using a function that calculates a number from a hash generated with this funcion hmac(server_key, current_bet_index + client_key)

When the user changes the client_key, the server key is also changed to the next one, and the old one is revealed giving the user a chance to check old bets.

  • I think we need more details of your system. From what you've written, I have no idea why you're sending a key, or what it's used for, or why the key has to be sent at the end, or why sending the hash doesn't mean you didn't change it before you sent the hash.
    – cpast
    Feb 22, 2015 at 20:26
  • @cpast too much to write on a comment, edit my question, please take a look Feb 22, 2015 at 20:43

1 Answer 1


My best understanding of your question is:

Given a hash, from a known hashing function, if I apply the hash to itself any number of times, shall I ever receive the same number again?

In that case the answer is "Possibly in a very,very,very,very long time depending on exactly what algorithm you use and how you use it."

A word about multi-hashing

At any rate, in a password context (which I realize is not your context) you wouldn't want to simply apply the same hash again and again blindly without understanding some deeper ramifications. In the case of passwords, you want to a iterative hashing solution that adds work to slow down crackers.


My advice to you

For the purposes of a card game it might make more sense to simply encrypt the clients cards, send them to the server, and send the results back to the user. In your system (as I understand it) logic pertaining to the win state is conducted in the client, which can be manipulated.

Instead, just ensure that there a secure connection between the client and the server, and do all the logic on the server side. Perhaps convoluted hashing set ups for online betting like this were made before the ubiquitous use of https.

What I think you are trying to do

I think the reason you providing the client the hash is so that you can provide some form of assurance that the game isn't rigged. You are trying to implement something like the below:


However, to accomplish this for a game like poker, you will have to develop a complex and will audited cryptographic system, which (while assuring the fairness of the game to a theorist) might do little to assure fairness to non technical user.

If you provide provide more information about what you are attempting to do, I'll do my best to update the answer.

  • ty for your answer, just a few considerations, 1. it is not a card game, it is a simple dice game (< or > then a given number), 2. I do not need to verify user's games, i need to provide ways to the user see that i did not rigged the game, 3. the hash generated by hmac function is read bit after bit and a single number is chosen. What i have at the moment it is provably fair and it works, i just need to verify if some "lucky streaks" (incredibly low chance of happening, close to 0.0001%) are pure luck or someone cheating. Feb 23, 2015 at 4:27
  • If it's a simple dice game, it's likely that all you need to do is perform a simple commitment scheme prior to a user making their choice. For instance, generate a random 256-bit value, and use those bits somehow to determine the outcome of the die roll. Before a user submits their guess, publish the hash of the value you used. Once the game is complete, publish the original value. Feb 23, 2015 at 8:23
  • @Stephen This is how we do it, but how do I check if someone hacked the system? I can prove the server was honest, but what about the user? Feb 24, 2015 at 10:27
  • The user submits their guess before they know anything about the outcome of the roll. What's the opportunity for a user to cheat? Feb 24, 2015 at 22:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .