Comment fonctionne le hachage de la seed serveur

Le rôle du hachage

Un casino provably fair a un problème à régler. Il doit garder sa seed serveur secrète pendant que vous jouez, parce que quiconque la connaît peut prédire les résultats. Mais il doit aussi prouver plus tard qu'il n'a pas changé la seed après avoir vu vos mises. Un hachage règle les deux problèmes à la fois.

Avant que vous jouiez, le casino vous montre le hachage SHA-256 de la seed serveur. Ce hachage est un engagement : il ne révèle rien d'utile sur la seed, mais il fixe la seed que le casino devra dévoiler plus tard. Quand la seed est dévoilée après la rotation, vous la hachez vous-même et vous comparez. Une correspondance prouve que le casino a utilisé la seed envers laquelle il s'était engagé.

Ce guide explique comment ça fonctionne et comment vérifier un hachage correctement. Pour le système dans son ensemble, voir qu'est-ce que le provably fair.

Ce qu'est SHA-256

SHA-256 est une fonction de hachage définie par le NIST dans la norme FIPS 180-4, le Secure Hash Standard. Elle accepte une donnée de n'importe quelle longueur et produit une sortie de 256 bits, généralement écrite sous forme de 64 caractères hexadécimaux.

Une valeur de test standard de la norme FIPS 180-4 est le texte de trois lettres abc. Son hachage SHA-256 est :

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

Si un outil vous donne ce résultat pour abc, il calcule SHA-256 correctement. C'est une façon rapide de tester un site Web ou un script avant de vous y fier.

Les trois propriétés qui font fonctionner l'engagement

Les deuxième et troisième propriétés dépendent du fait que la seed soit difficile à deviner, ce dont il est question plus bas.

Un exemple concret

Nous avons calculé ces valeurs en Python avec le module standard hashlib.

Seed serveur (en tant que texte) : a7c41e09d5b3f28e6c1d4a90b7e35f12c8d06e4b9a2f71c35e8d0b6a4f19c27e

SHA-256 de ce texte : 3e29712c704eeff2d868f958cf08e44a1a16ecba4c974af0496e13bccdefaff2

Un seul caractère change tout

Changez seulement le dernier caractère de la seed, de e à f, et le hachage devient :

af4391b73bb5adf912b7a7296ee8f79dda892ddbb47e5e4c38efeaaf2d82de7c

Il n'y a aucun lien visible entre les deux hachages. C'est pourquoi une quasi-correspondance ne veut rien dire : soit chaque caractère correspond, soit l'engagement a échoué.

Texte ou octets : la cause la plus courante d'une fausse alerte

Une seed serveur est généralement affichée sous forme de 64 caractères hexadécimaux. Ces caractères peuvent être hachés de deux façons différentes :

• En tant que texte. Les 64 caractères eux-mêmes constituent la donnée d'entrée.
• En tant qu'octets. L'hexadécimal est d'abord décodé en 32 octets bruts, et ce sont ces octets qui constituent la donnée d'entrée.

Pour notre seed d'exemple :

Les deux sont des résultats SHA-256 valides de données différentes. Le système courant hache le texte exactement tel qu'il est affiché, et c'est ce que fait notre vérificateur. Si votre hachage ne correspond pas, lisez la documentation d'équité du casino pour savoir quelle méthode il utilise avant de tirer des conclusions.

Deux autres façons d'obtenir le mauvais hachage

Un retour à la ligne caché

Sous Linux et macOS, echo ajoute un retour à la ligne à la fin de sa sortie. Hacher avec echo seed | sha256sum hache donc la seed plus un retour à la ligne. Pour notre seed d'exemple, ça donne :

60f1c7bdca64b07819a42ddf185c24d093fe41bce96f41f029422f16bc9c50b5

ce qui ne correspond pas. Utilisez plutôt printf %s seed | sha256sum ou echo -n seed | sha256sum. Le même problème survient si vous copiez une seed avec une espace ou un saut de ligne à la fin.

Une casse modifiée

L'hexadécimal peut s'écrire en minuscules ou en majuscules, mais hacher le texte traite a et A comme des caractères différents. Si le casino affiche des minuscules, hachez des minuscules.

Vérifier un hachage vous-même

N'importe laquelle de ces méthodes fonctionne, en utilisant la seed exactement comme le casino l'affiche :

• Notre vérificateur : collez la seed serveur et comparez le hachage affiché.
• Python : hashlib.sha256(seed.encode()).hexdigest()
• Un terminal : printf %s 'seed' | sha256sum

Comparez les 64 caractères avec le hachage que vous avez enregistré avant de jouer, pas avec celui que le casino vous montre maintenant. Un site malhonnête pourrait modifier à la fois la seed dévoilée et le hachage affiché dans son historique. Votre copie enregistrée est la seule qu'il ne peut pas modifier.

Pourquoi la seed doit être longue et aléatoire

L'engagement ne cache la seed que si celle-ci ne peut pas être devinée. SHA-256 est rapide, alors un attaquant peut essayer de nombreuses données par seconde.

Pour le démontrer, nous avons haché la seed à six chiffres 482913, puis essayé chaque nombre de 000000 à 999999 jusqu'à ce qu'un d'eux corresponde. Une simple boucle Python sur un ordinateur ordinaire l'a trouvée en bien moins d'une seconde. Une seed qui n'offre qu'un million de possibilités n'offre aucun secret.

Une seed hexadécimale de 64 caractères représente 256 bits, ce qui dépasse de loin ce que quiconque peut parcourir. Les bons casinos génèrent leurs seeds avec un générateur de nombres aléatoires cryptographiquement sûr. Vous ne pouvez pas vérifier comment une seed a été générée, mais vous pouvez vérifier que les seeds dévoilées ont leur pleine longueur et ne se répètent jamais. Une seed courte, prévisible ou réutilisée est une constatation qui mérite d'être signalée.

La place du HMAC

Le hachage engage envers la seed. Une construction différente transforme la seed en résultats : HMAC-SHA256, défini dans la RFC 2104 et dans la norme NIST FIPS 198-1. Dans le système courant, la seed serveur est la clé HMAC et clientSeed:nonce:round est le message. Le HMAC est conçu pour que la sortie d'un message ne permette ni de retrouver la clé ni de prédire la sortie d'un autre message. C'est pourquoi voir vos résultats passés ne révèle pas la seed serveur. Notre explication du dice montre le HMAC étape par étape.

Ce que le hachage ne prouve pas

• Que la seed a été choisie équitablement. Le hachage fixe la seed; il ne montre pas comment elle a été choisie. C'est la seed client qui s'en charge, parce que le casino ne peut pas adapter une seed à une valeur qu'il n'a pas vue.
• Que les résultats en ont été calculés. Vous le prouvez en recalculant les mises.
• Quoi que ce soit sur les jeux de tiers. Les machines à sous et les tables en direct n'utilisent pas vos seeds.

Les chaînes de hachages dans les jeux multijoueurs

Certains jeux à résultat partagé, comme bien des jeux crash, n'utilisent pas de seeds par joueur. L'opérateur génère plutôt une longue chaîne où la seed de chaque partie est le hachage SHA-256 de la seed de la partie suivante, et publie le hachage final à l'avance. Comme le hachage ne fonctionne que dans un sens, l'opérateur ne peut pas modifier les parties futures sans briser la chaîne, et n'importe qui peut vérifier une partie dévoilée en la hachant vers l'avant. Les détails varient beaucoup d'un casino à l'autre; suivez donc les instructions propres à chaque casino pour ces jeux.

Liste de vérification rapide

Sources

• NIST FIPS 180-4, Secure Hash Standard: https://csrc.nist.gov/pubs/fips/180-4/upd1/final
• RFC 2104, HMAC: Keyed-Hashing for Message Authentication: https://datatracker.ietf.org/doc/html/rfc2104
• NIST FIPS 198-1, The Keyed-Hash Message Authentication Code (HMAC): https://csrc.nist.gov/pubs/fips/198-1/final
• Documentation Python, module hashlib : https://docs.python.org/3/library/hashlib.html
• Documentation Python, module hmac : https://docs.python.org/3/library/hmac.html