[Jeu Provably-Fair] P01 L'axe cryptographique - E02 Le protocole SHA256

Bonjour chers amis Steemiens,

Cet article fait suite au post explicatif du concept de provably-fair.
Pour rappel, le but de cette série est d'aboutir à la création d'un jeu provably-fair sur le modèle de Bustabit. Bien entendu, il ne s'agit pas de faire une copie conforme, mais de s'en inspirer pour créer un jeu semblable, basé sur le même principe, mais s'en démarquant (pour des raisons évidentes, la différence ne sera pas dévoilée).

Donc nous allons aujourd'hui continuer notre progression sur l'axe cryptographique, dont les 3 parties sont :

1. Explication du concept de provably-fair (ce que nous avons vu dans le précédent post),
2. Présentation de l'algorithme cryptographique SHA256 qui va être utilisé pour la création de ce jeu (ce que nous allons voir dans le présent post),
3. Comment générer une hash chain (une chaîne de résultats) en Python. Ce 3^ème article sera peut-être fait en stream (DLive) - idée d'@alucare - mais sera quoi qu'il arrive aussi publié sous forme d'article "classique".
   
   

Partie 2 : Le protocole SHA256

Ou comment assurer la sécurité du joueur ET de l'opérateur ?

Présentation

L'algorithme SHA (Secure Hash Algorithm) permet la vérification de l'intégrité de données. En hashant un fichier, une chaîne de caractères ou des données numériques (= l'intrant), un résultat (= l'extrant, un hash) est généré. En comparant ce résultat aux futurs hashs de ce même fichier, on peut voir si le fichier a été altéré (générant alors un extrant différent) ou non (générant toujours le même hash).

Pour assurer l'utilité et la fiabilité de tels algorithmes cryptographiques, il faut être sûr que deux intrants différents ne peuvent générer le même résultat (extrant, hash). Ceci est appelé la résistance aux collisions.

Une fonction de hachage cryptographique H est résistante aux collisions s'il est difficile de trouver deux entrées qui donnent la même valeur de hachage; c'est-à-dire deux entrées telles que :
H(A) = H(B) et A =/= B (A différent de B)

^{Définition issue de Wikipédia}

On parle bien dans cette définition de difficile et non d'impossible, car comme nous allons le voir, les algorithmes SHA-2 (je ne connais pas suffisamment les autres pour me prononcer) sont sujets à collision, tout dépend de la puissance de calcul dédiée à la recherche d'une telle collision. Le but d'un algorithme cryptographique est de rendre cette entreprise la plus difficile possible.

Le protocole SHA256 est utilisé pour le Bitcoin :

• Dans la génération des adresses,
• Dans le processus de minage.
  
  

Le HASH

^{Source : CECS}

A quoi ressemble un hash ? Nous allons ici illustrer nos propos en utilisant le protocole SHA256.
En cryptant une chaîne de caractères, un fichier ou n'importe quelle donnée numérique via le protocole SHA256, on obtient un résultat sous forme de hash de 32 nombres hexadécimaux (soit 64 caractères).

Voici un exemple :
En cryptant

Bonjour Steemit !

J'obtiens

c3140aeb8e0e03587509acc6dd75544bb6cdfa3da6b36640848e4c0b4e147d98

Nous verrons dans la partie 3 comment crypter de manière simple en Python. Tous les langages informatiques (ou presque) ont par défaut les principaux algorithmes cryptographiques intégrés sous forme de fonctions. Vous pouvez aussi crypter des fichiers directement sur Internet, plusieurs sites proposent ces services : ici ou ici. Vous pouvez d'ailleurs vérifier que le "Bonjour Steemit !" de notre exemple génère toujours, sans exception, le même hash.

Il n'y a pas besoin pour nous, dans ce projet, de comprendre comment l'algorithme fonctionne en tant que tel et comment il convertit un intrant en extrant.

Ce qui nous intéresse, c'est d'être certain que l'algorithme que nous allons utiliser (SHA256) est bien résistant aux collisions, car s'il ne l'est pas, cela pourrait permettre aux joueurs de reconstituer notre hash chain et ainsi de connaître à l'avance les résultats des parties, ce qui ne pourrait que mener à la ruine l'opérateur.

La résistance aux collisions

^{Creator : ChaosNet1701}

Comme nous l'avons vu précédemment, la seule chose qui pourrait compromettre un algorithme cryptographique comme le protocole SHA256 serait une collision (deux entrées différentes qui donneraient le même résultat, le même hash en sortie).

Quelles sont les chances pour que cela se produise ?
Galvatron a donné une réponse éloquente sur Stack Exchange : Si on utilisait toute la puissance de calcul dédiée au réseau Bitcoin (des mineurs), cela prendrait 39 fois l'âge de l'univers pour trouver une collision, sans prendre en compte toutes les problématiques liées au stockage des différents essais et de comparaison avec le reste du réseau (pour ne pas faire de travail en double). Les chiffres évoqués dans cet article datent de 2015. Depuis la puissance de calcul cumulée a été multipliée par 100, trouver une collision pour l'algorithme SHA256 prendrait théoriquement plus de 5 milliards d'années avec toute la puissance des mineurs sur le réseau Bitcoin.

Bien entendu, avec l'arrivée de nouvelles technologies, des collisions pourraient se produire (augmentation de la puissance de calcul, systèmes quantiques) mais de nouveaux algorithmes cryptographiques répondent déjà à ces nouveaux défis.

Retour à notre jeu provably-fair

Cet article était en quelque sorte une digression, pour bien comprendre le système cryptographique qui va permettre d'assurer la sécurité de notre jeu.

L'algorithme SHA256 satisfait pleinement nos exigences :

• Pour l'opérateur (les jeux ne sont pas prévisibles),
• Pour les joueurs (les jeux ne sont pas truqués).

Grâce à la cryptographie, on a une garantie :

• à la fois pour les joueurs, qui peuvent s'assurer que l'opérateur suit bien la hash chain qu'il a défini, ne pouvant la modifier en cours de route sans que les joueurs s'en aperçoivent (le seul moyen qu'il aurait de faire ça est d'avoir trouvé une collision, ce qui est théoriquement impossible avec sa seule puissance de calcul),
• et aussi pour l'opérateur, qui est assuré que les joueurs ne pourront prévoir les futurs jeux (car de la même manière, pour ce faire, il leur faudrait soit trouver une collision soit trouver son hash originel, mais nous verrons comment s'assurer que cela n'arrive pas dans le prochain article).

J'espère que vous avez apprécié cette lecture !

Si vous avez des questions, des suggestions ou quoi que ce soit, je me ferai un plaisir de discuter avec vous dans les commentaires !

Bientôt la partie 3 : Générer une hash chain en Python. La préparation prendra peut-être un peu de temps si je me décide à le faire sur DLive, si vous êtes intéressé de voir cette étape de programmation en stream, merci de me l'indiquer dans les commentaires. S'il n'y a personne d'intéressé, je le ferai uniquement via un article, de manière classique.