Provably Fair Calculator: Reproducing the HMAC Math by Hand
How a seed verifier runs HMAC-SHA256 on the server seed, how to check it against IETF test vectors, and the one thing no calculator can ever prove.
A provably fair calculator recomputes a game result from seeds the casino reveals after play. It runs HMAC-SHA256 with the server seed as the key and the client seed plus nonce as the message, then maps the digest to an outcome. You can reproduce that arithmetic by hand, and you should validate the calculator against published test vectors before trusting it. What no calculator can prove is that the server seed was fixed before you bet.
What the calculator actually computes
HMAC is a hash wrapped inside another hash. The IETF definition is an inner hash inside an outer hash: H(K XOR opad, H(K XOR ipad, text)). In casino terms, K is the server seed and the text is the client seed and nonce string.
The two pads are fixed. The inner pad is the byte 0x36 repeated across the block, and the outer pad is a different fixed byte repeated the same way. The specification allows keys up to the block size, so a long hex server seed is handled without truncation tricks.
| Step | Input | Operation |
|---|---|---|
| Key prep | Server seed | XOR with inner pad and, separately, with outer pad |
| Inner hash | Padded key plus client seed and nonce | SHA-256 |
| Outer hash | Outer-padded key plus inner digest | SHA-256 |
| Mapping | Final digest | Game-specific conversion to a roll, card or tile |
Test the tool before you test the casino
A calculator is just code, and code can be wrong. The IETF publishes fixed HMAC-SHA-256 test vectors for exactly this purpose. One case is labelled a test with a key shorter than the HMAC output (key "Jefe"), which mirrors short client inputs. For the "Hi There" case, the expected output for the first published HMAC-SHA-256 vector begins b0344c61d8db38535ca8afceaf0bf12b. If a provably fair calculator cannot reproduce that, its casino results are not evidence of anything.
Working one round by hand
SHA-256 pads every message to whole blocks so that its length is a multiple of 512 bits. Every HMAC call therefore processes complete blocks, whatever the seed length. By hand, or in any HMAC library you already trust:
- Take the revealed server seed as the key.
- Build the message from the client seed and nonce in the format the casino documents.
- Compute HMAC-SHA256 and compare the digest with the calculator's.
- Apply the game's documented mapping to that digest.
If your digest matches but the outcome does not, the dispute is in the mapping, not the hash. Our walkthrough of the provably fair hi lo game shows that mapping step for cards.
What a calculator cannot prove
A matching digest proves consistency, not commitment. The calculator accepts whatever server seed you paste. Fairness depends on the casino having shown a hash of that seed before your first bet with it, and on you having recorded that hash. Hash the revealed seed with SHA256 and compare. Without that saved commitment, a correct calculator confirms only that the casino's arithmetic is internally consistent.
Questions on this
What inputs does a seed verifier need?
The revealed server seed, your client seed and the nonce of the round. The server seed is the HMAC key; the client seed and nonce make up the message, and the result is read from the digest.
How do I know a verifier implements HMAC correctly?
Feed it the IETF test cases before any casino seeds. If the "Hi There" case does not open with the published digest prefix, its output on your bets means nothing.
Can a calculator show that the casino kept the same server seed?
No. It only shows that the seeds you typed produce the result you saw. Whether that server seed was fixed before the bet depends on the hash the casino showed you earlier, which you have to compare yourself.
Why does message length not change the HMAC procedure?
SHA-256 pads every input to whole blocks before hashing, so short seeds and long ones go through the same block-by-block process.
Sources and on-chain links
- IETF / RFC Editor, RFC 2104: HMAC: Keyed-Hashing for Message Authentication, 1997-02-01
- IETF / RFC Editor, RFC 4231: Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512, 2005-12-01
- IETF / RFC Editor, RFC 6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF), 2011-05-01
