Sportingbet.com

Pourquoi Paradise

Génération de nombres aléatoires

La section suivante traite certaines questions relatives à la génération de nombres aléatoires et sa relation avec le battage des cartes lors d'une partie de poker multi-joueurs en ligne. Nous sommes convaincus que le rigoureux examen public des algorithmes utilisés pour générer des nombres et battre les cartes de manière aléatoire est la seule façon de garantir que nous offrons la meilleure solution du secteur. Nous consultons en permanence les forums et les listes de diffusion relatives à la cryptographie afin de nous assurer que nos solutions demeurent les meilleures. Nous ne doutons pas que vous partagerez cette opinion dès que vous aurez pris connaissance de nos méthodes.

La génération de nombres aléatoires pour la sécurisation des données et le battage des cartes lors d'une partie de poker multi-joueurs en ligne partagent un certain nombre de thématiques communes. Dans les deux cas, l'objectif est de produire un nombre (ou une série de nombres) ne pouvant pas être prédit à l'aide des données disponibles. Toutes deux présentent le risque qu'un adversaire utilise un ordinateur pour réduire le nombre de possibilités et toutes deux peuvent bénéficier des mêmes solutions. Un germe de grande taille et un moteur d'entropie imprévisible et diversifiée sont essentiels aux deux applications.

Commençons par un peu de mathématiques pour mieux comprendre l'importance d'un germe de grande taille et la raison pour laquelle nous n'utilisons PAS la fonction rand() standard utilisée par les compilateurs actuels :

Prenons comme exemple le cas du Seven Card Stud... si l'on dispose d'un germe de 32 bits pour un générateur de nombres aléatoires (la taille la plus commune dans les compilateurs de programmes actuels), on obtient plus de 4 milliards de façons de mélanger le paquet de cartes. Cela semble énorme, mais vous allez voir que c'est loin d'être suffisant.

Après la distribution du premier tour de cartes, vous voyez vos trois cartes, plus une carte pour chacun de vos sept adversaires. Au total, dix cartes sont donc visibles. La première carte divise le nombre de germes possibles par un facteur de 52, la seconde de 51 et la troisième de 50. Effectuons la multiplication et voyons ce que nous obtenons...

52*51*50*49*48*47 = 14.65 milliards.

Avant que six cartes ne soient visibles (il n'est même pas nécessaire d'arriver jusqu'à dix), il n'existe plus d'autre résultat possible (14 milliards dépassent 4 milliards) et un adversaire donné peut facilement prédire chacune des cartes distribuées et à distribuer jusqu'à la fin de la partie. En fait, un germe de 32 bits ne suffit même pas à garantir que le joueur 1 n'obtient pas plus de paires d'as qu'il ne le devrait ! De toute évidence, cette solution n'est pas du tout adaptée au poker multi-joueurs. Mais heureusement, il existe une solution.

Continuons la multiplication et reprenons l'exemple du Seven Card Stud...avant que toutes les cartes ne soient distribuées, vos sept cartes seront visibles, plus quatre pour chacun de vos sept adversaires, soit un total de 28 cartes visibles (plus de la moitié du paquet).

52*51*50*49...*26*25 = 52!/24! = 1.3*1044 (soit 13 suivi de 43 zéros, ou environ 2 147).

Comme vous pouvez le constater, même un germe de 147 bits réduit tout juste le nombre de possibilités à 1 avant même que la dernière carte ne soit factorisée. De toute évidence, il faut utiliser un germe de plus grande taille.

En fait, un paquet de cartes peut être battu de 52! manières différentes (environ 8 x 1 067, ou 2 225). Essayer de battre un paquet de cartes à l'aide d'un simple germe de 32 bits, comme le font d'autres logiciels de poker, permet d'obtenir un maximum de 4 milliards de combinaisons. Cela ne représente pas plus de 0,000000000000000000000000000000000000000000000000000000005 % (ou 5 x 10-57 %) des combinaisons possibles. Nettement insuffisant.

Sur ParadisePoker, nous avons choisi d'utiliser un germe de 2 016 bits. On peut considérer que c'est de l'exagération ou de la paranoïa, mais nous pensons que le jeu en vaut la chandelle. Cette méthode, combinée à notre algorithme de mélange, nous permet de mélanger un paquet de manière à ce que TOUS les mélanges possibles soient réellement possibles.

Mais quelle serait l'utilité d'un germe de 2 016 bits sans données aléatoires ? En supposant, pour les besoins de l'exemple, que chaque main dure environ 120 secondes (parfois plus, parfois moins) et que nous ayons besoin d'au moins 2 000 nouveaux bits pour modifier notre germe à chaque main (exagération), nous devrons ajouter environ 17 nouveaux bits complètement aléatoires (imprévisibles) par seconde à l'entropie de notre germe.

Il existe deux principales sources de bits aléatoires. Tout d'abord, le RNG (générateur de nombres pseudo-aléatoires) du serveur échantillonne les bits de poids faible du compteur de cycles (TSC) (667 MHz) de l'unité centrale sur des parties irrégulières du programme d'une part, et lorsque des données sont reçues par le biais de la connexion des clients d'autre part, et les utilise pour ajouter de l'entropie à notre germe de grande taille.

Ensuite (et surtout), chaque logiciel client envoie ses 32 bits d'entropie à chaque action et avec plusieurs autres paquets envoyés au serveur. L'entropie du client est prélevée par le biais des mouvements de la souris et du clavier, de même que les 32 bits de poids faible des compteurs de cycles de son unité centrale. Les milliers de clients connectés, qui utilisent différentes sortes de matériel informatique et déplacent leur souris de manière imprévisible, constituent de loin la principale source d'entropie et nous permettent d'obtenir bien plus de 17 nouveaux bits aléatoires par seconde. En fait, des tests menés en février 2001 indiquent que cette méthode permet de récupérer en moyenne plus de 7 000 bits de nouvelles données aléatoires par seconde. Nous utilisons plusieurs sources d'entropie aléatoire fiable, ce qui nous permet de parer à toutes les éventualités. Vous pensez toujours que nous exagérons ?

Il est important de savoir que ces nouveaux bits ne remplacent pas les bits du germe existant. Ils modifient simplement le germe existant (XOR) afin de le rendre moins prévisible. Même si un pirate était capable d'envoyer des données non aléatoires (probablement permanentes) au lieu de l'entropie que nous attendons, il resterait toujours suffisamment de nouvelles informations aléatoires provenant d'autres clients et du serveur lui-même pour garantir que nous distribuons des cartes mélangées de manière réellement aléatoire.

Le germe actualisé est utilisé pour distribuer les cartes à chaque tour et, puisqu'une main dure toujours plus de temps qu'il n'en faut pour injecter 2 000 bits de nouvelles données aléatoires, toutes les cartes suivantes sont distribuées en utilisant un germe complètement aléatoire et totalement indépendant du germe utilisé pour distribuer les mains précédentes.

Que demander de plus ?

Le générateur de nombres aléatoires lui-même est basé sur le PRNG (générateur de nombres pseudo-aléatoires) de Berkeley, qui utilise une table d'états de 64 longs. Nous l'avons modifié pour pouvoir changer l'état du germe sans avoir à sauvegarder/restaurer, mais mis à part cela, il s'agit d'un algorithme qui a été étudié pendant des années par des professionnels de la sécurisation des données.

Nous sommes fiers de pouvoir affirmer que nous offrons ce niveau de sécurité à nos clients depuis le premier jour. Vous serez certainement d'accord pour dire qu'il s'agit, de loin, de la solution de mélange la plus complète du marché des sites de poker sur Internet.

Retour

1 2 3

Suivant

|Not yet part of Paradise? - Play Poker Now|