Say a server plays a game of blackjack with a client, and the cards are shuffled and dealt by the server. The shuffle itself may or may not be fair, but what needs to be shown is that the cards dealt weren't altered during the course of gameplay, ie: after the start of the hand, the cards in the deck do not secretly have their ordering changed by the server.
I was thinking of the following solution using cryptography and wanted to gain some feedback if it would be acceptable for a production system, and if not, why not:
Step 1) The server would secretly shuffle a deck of cards in some order, say the following (we omit the suit for simplicity): [3, 9, 2, ..., A]
It would then create the following message M:
M = "Card shuffle: [3, 9, 2, ..., A]. Random number: A96A...QT3"
Random number is a random number the server internally generates and keeps secret until the game concludes. Its length would be long enough to prevent the hash being cracked by the client via brute force (let's say it's 512 characters in length).
The server would now hash M using sha-256 or some other trusted hashing algorithm, eg: hash(M)
Step 2) Before the game begins, the server sends this hash(M) to the client, which the client stores. The client has no way of knowing M from what I can gather.
Step 3) The game begins, the cards are dealt in the shuffled order, the player makes decisions, and the game finally concludes.
Step 4) The client now wants to know that the game was fair, ie: the server didn't cheat by altering the cards during the hand. The server now sends the message "M" to the client in plaintext to show this.
Step 5) The client runs hash(M) and see's that it matches its hash(M) received in step 1.
Is this a fair way to prove the game was fair, without the client or server being able to cheat, excluding the possibility that the shuffle itself wasn't random? If the server were to alter the cards from the original shuffle during the course of the hand, then the client would see this in Step 5 (either the ordering would be transparently different to the client, or the hash of the message sent in Step 4 would be different to the one sent in step 2). Also, only a single hash is sent per hand, so the server can't generate a large number of hashes and send them separately then pick the best one during the course of the hand.