How a certified game version is checked: hashes and signatures

A hash is a fixed-length fingerprint computed from a file. If the fingerprint of the live game files equals the fingerprint recorded at certification, the files are the same. A digital signature adds proof of who issued that record. Kenyan rules require re-testing and notification of changes, but do not describe the hash method.

By Nairobi Ultimate Editorial (prepared with AI tools under our editorial policy) · Last updated 2026-11-03

The short answer

When a test laboratory certifies a game, it examines one exact set of files. Later, someone needs a quick way to confirm that the files running on a server are still that set. A hash does this job.

This guide explains the idea in plain terms, shows where it fits in the certification chain described in Kenyan rules, and is clear about what the rules say and what they leave unsaid.

What a hash is

NIST, the United States standards body, describes a hash algorithm as one that maps a message of arbitrary length to a fixed-length message digest. FIPS 180-4, the Secure Hash Standard, specifies the SHA-2 family, which includes SHA-256. According to NIST, SHA-256 produces a 256-bit output.

A digest is a fingerprint, not a copy. A 50 MB game package and a one-line text file both produce a digest of the same length, and the digest cannot be turned back into the file. NIST defines this one-way property as the computational infeasibility of finding any input that maps to a pre-specified output.

Illustrative example. A SHA-256 digest has 256 bits. One hexadecimal character stands for 4 bits, so the digest is written with 256 / 4 = 64 characters. The package could be 50 MB or 500 MB and the written digest is still 64 characters.

Why matching hashes mean matching files

NIST defines collision resistance as the computational infeasibility of finding any two distinct inputs that map to the same output. If that holds, two files with the same digest are, for practical purposes, the same file. Change one file in the package, even slightly, and the check should no longer match.

The security strength matters too. NIST lists SHA-256 with a collision resistance strength of 128 bits and a preimage resistance strength of 256 bits. A strength of 128 bits means roughly 2^128 operations of effort, a number so large that guessing is not a realistic route to a forged match.

Where the check fits in the certification chain

Rows 2, 4 and 5 are marked as general practice because the Kenyan regulations read for this guide do not describe a hashing or signature procedure. They set the duties (certify, notify, re-test) and leave the technical means to the laboratory and supplier. For the testing side, see the guide to how RNG testing and certification work in Kenya.

What a digital signature adds

A hash on its own is only as trustworthy as the place it is stored. Someone who could change a game file could also write a new matching digest next to it. A digital signature closes that gap.

NIST sources define a digital signature as a result that, when properly implemented, provides origin authentication, data integrity and signatory non-repudiation. In SP 800-63-4 the mechanism is described as one where a private key signs and a public key verifies. Anyone with the public key can check the record, but only the holder of the private key could have produced it.

A worked comparison

Illustrative example. A certified package has three files, A, B and C. The signed record lists a digest for each. On a later check, the verifier recomputes the digests of the files on the server.

1. File A: recomputed digest equals the record. Match.
2. File B: recomputed digest equals the record. Match.
3. File C: recomputed digest differs from the record. Mismatch.

Two of three files match, but the package as a whole does not. The mismatch says that file C is not the certified file. It does not say why: an authorised update that was never recorded, a corrupted copy and a deliberate alteration all look the same. The follow-up is a question for the supplier and the regulator, and the rules on notification and re-testing are what give that question force.

What a hash check cannot show

• Whether the game is fair. A hash says the files are unchanged, not that the certified version was good. Fairness comes from the testing itself, as in the guide to statistical tests such as chi-square.
• Settings outside the files. If a percentage lives in a configuration or database value that the hash does not cover, the files can match while a setting differs. Regulation 45(3) therefore requires the theoretical return to be publicly disclosed and the rules evaluated annually.
• Anything about an unlicensed site. Rules attach to licence holders. A hash badge on an unlicensed site has no regulator behind it.

The related question of what happens to the declared percentage after certification is covered in the guide on whether a casino can change a certified game's RTP.

Not the same as a provably fair hash

Some crash and dice games publish a hash for a different purpose: to commit to a hidden value before a round is played so that it cannot be swapped afterwards. That use is explained in the guide to provably fair seeds and hashes. It checks a single round result, not the version of the whole game software.

Laboratories publish their technical standards publicly; for example, Gaming Laboratories International lists GLI-19, Interactive Gaming Systems v3.0, on its standards page. The licensing side of laboratories in Kenya is covered in the guide to the gambling equipment testing licence.

Gambling is addictive. Play responsibly, only with money you can afford to lose, and remember that a verified game still has a built-in cost. The 18+ rule applies.