{"id":95468,"date":"2020-09-29T19:42:29","date_gmt":"2020-09-29T17:42:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1"},"modified":"2020-09-29T19:42:29","modified_gmt":"2020-09-29T17:42:29","slug":"mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","title":{"rendered":"Peut-on g\u00e9n\u00e9rer des nombres al\u00e9atoires si nous ne nous faisons pas confiance ? Partie 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Salut, Habr !<\/p>\n

Dans cet article, je vais parler de la g\u00e9n\u00e9ration de nombres pseudo-al\u00e9atoires par des participants qui ne se font pas confiance. Comme nous le verrons ci-dessous, r\u00e9aliser un g\u00e9n\u00e9rateur \u00ab presque \u00bb bon est assez simple, mais en cr\u00e9er un tr\u00e8s bon est difficile.<\/p>\n

Pourquoi g\u00e9n\u00e9rer des nombres al\u00e9atoires pour des participants qui ne se font pas confiance ? L'une des applications est celle des applications d\u00e9centralis\u00e9es. Par exemple, une application qui accepte un pari d'un participant et double la mise avec une probabilit\u00e9 de 49%, ou la prend avec une probabilit\u00e9 de 51%, ne fonctionnera que si elle peut obtenir un nombre al\u00e9atoire de mani\u00e8re impartiale. Si un attaquant peut influencer le r\u00e9sultat du g\u00e9n\u00e9rateur de nombres al\u00e9atoires, m\u00eame l\u00e9g\u00e8rement augmenter ses chances de recevoir un paiement dans l'application, il peut facilement la vider.<\/p>\n

Lorsque nous d\u00e9veloppons un protocole distribu\u00e9 de g\u00e9n\u00e9ration de nombres al\u00e9atoires, nous voulons qu'il poss\u00e8de trois propri\u00e9t\u00e9s :<\/p>\n

    \n
  1. \n

    Il doit \u00eatre impartial. En d'autres termes, aucun participant ne doit avoir d'influence sur le r\u00e9sultat du g\u00e9n\u00e9rateur de nombres al\u00e9atoires.<\/p>\n<\/li>\n

  2. \n

    Il doit \u00eatre impr\u00e9visible. En d'autres termes, aucun participant ne doit pouvoir pr\u00e9dire quel nombre sera g\u00e9n\u00e9r\u00e9 (ou en d\u00e9duire certaines de ses propri\u00e9t\u00e9s) avant qu'il ne soit g\u00e9n\u00e9r\u00e9.<\/p>\n<\/li>\n

  3. \n

    Le protocole doit \u00eatre viable, c'est-\u00e0-dire r\u00e9sistant \u00e0 ce qu'un certain pourcentage de participants se d\u00e9connecte du r\u00e9seau ou tente intentionnellement d'arr\u00eater le protocole.<\/p>\n<\/li>\n<\/ol>\n

    Dans cet article, nous examinerons deux approches : RANDAO + VDF et une approche bas\u00e9e sur des codes de correction d'effacement. Dans la prochaine partie, nous d\u00e9taillerons l'approche bas\u00e9e sur des signatures seuil.<\/p>\n

    Mais d'abord, examinons un algorithme simple et souvent utilis\u00e9 qui est viable, impr\u00e9visible mais biais\u00e9.<\/p>\n

    RANDAO<\/h3>\n

    RANDAO est une m\u00e9thode tr\u00e8s simple et donc assez souvent utilis\u00e9e pour obtenir de l'al\u00e9a. Tous les participants du r\u00e9seau choisissent d'abord localement un nombre pseudo-al\u00e9atoire, puis chaque participant envoie le hash du nombre choisi. Ensuite, les participants r\u00e9v\u00e8lent tour \u00e0 tour leurs nombres choisis et effectuent une op\u00e9ration XOR sur les nombres r\u00e9v\u00e9l\u00e9s, et le r\u00e9sultat de cette op\u00e9ration devient le r\u00e9sultat du protocole.<\/p>\n

    Un pas de publication des hachages avant de r\u00e9v\u00e9ler les nombres est n\u00e9cessaire pour que l'attaquant ne puisse pas choisir son nombre apr\u00e8s avoir vu les nombres des autres participants. Cela lui permettrait en fait de d\u00e9terminer seul la sortie du g\u00e9n\u00e9rateur de nombres al\u00e9atoires.<\/p>\n

    Tout au long du protocole, les participants doivent parvenir \u00e0 un consensus \u00e0 deux reprises : d'abord sur le moment de r\u00e9v\u00e9ler les nombres choisis, puis de cesser d'accepter les hachages, et ensuite sur le moment de cesser d'accepter les nombres choisis et de calculer le r\u00e9sultat. Prendre de telles d\u00e9cisions entre des participants qui ne se font pas confiance est en soi une t\u00e2che difficile, et nous y reviendrons dans de futurs articles. Dans cet article, nous supposerons qu'un tel algorithme de consensus est \u00e0 notre disposition.<\/p>\n

    Quelles sont les propri\u00e9t\u00e9s d\u00e9crites ci-dessus qui s'appliquent \u00e0 RANDAO ? Il est impr\u00e9visible, poss\u00e8de la m\u00eame viabilit\u00e9 que le protocole de consensus qui le sous-tend, mais il est biais\u00e9. En particulier, un attaquant peut observer le r\u00e9seau, et une fois que d'autres participants ont r\u00e9v\u00e9l\u00e9 leurs nombres, il peut calculer leur XOR et d\u00e9cider de r\u00e9v\u00e9ler ou non son nombre pour influencer le r\u00e9sultat. Bien que cela ne permette pas \u00e0 l'attaquant de d\u00e9terminer seul la sortie du g\u00e9n\u00e9rateur de nombres al\u00e9atoires, cela lui donne tout de m\u00eame 1 bit d'influence. Et si les attaquants contr\u00f4lent plusieurs participants, le nombre de bits qu'ils contr\u00f4lent sera \u00e9gal au nombre de participants sous leur contr\u00f4le.<\/p>\n

    \"Peut-on<\/p>\n

    L'influence des attaquants peut \u00eatre fortement r\u00e9duite en exigeant que les participants r\u00e9v\u00e8lent leurs nombres dans l'ordre. Dans ce cas, l'attaquant ne pourra influencer le r\u00e9sultat que s'il est le dernier \u00e0 se r\u00e9v\u00e9ler. Bien que l'influence soit consid\u00e9rablement r\u00e9duite, l'algorithme reste biais\u00e9.<\/p>\n

    RANDAO + VDF<\/h3>\n

    Une des options pour rendre RANDAO impartial est la suivante : apr\u00e8s que tous les nombres ont \u00e9t\u00e9 r\u00e9v\u00e9l\u00e9s et que le XOR a \u00e9t\u00e9 calcul\u00e9, le r\u00e9sultat est introduit dans une fonction qui prend beaucoup de temps \u00e0 calculer, mais permet de v\u00e9rifier la pr\u00e9cision du calcul tr\u00e8s rapidement.<\/p>\n

    (vdf_output, vdf_proof) = VDF_compute(input) \/\/ c'est tr\u00e8s lent\ncorrect = VDF_verify(input, vdf_output, vdf_proof) \/\/ c'est tr\u00e8s rapide<\/code><\/pre>\n
    Cette fonction s'appelle Verifiable Delay Function, ou VDF. Si le calcul du r\u00e9sultat final prend plus de temps que la phase de divulgation des nombres, un attaquant ne pourra pas pr\u00e9dire l'effet de la d\u00e9monstration ou de la dissimulation de son nombre, et par cons\u00e9quent il perdra la capacit\u00e9 d'influencer le r\u00e9sultat.<\/p>\n
    Le d\u00e9veloppement de bons VDF est extr\u00eamement difficile. R\u00e9cemment, plusieurs avanc\u00e9es ont \u00e9t\u00e9 r\u00e9alis\u00e9es, par exemple celui-ci<\/u><\/a><\/noindex> et celle-ci,<\/u><\/a><\/noindex> qui ont rendu les VDF plus applicables en pratique, et Ethereum 2.0 pr\u00e9voit \u00e0 long terme d'utiliser RANDAO avec VDF comme source de nombres al\u00e9atoires. En plus du fait que cette approche est impr\u00e9visible et impartiale, elle a l'avantage suppl\u00e9mentaire d'\u00eatre viable tant qu'au moins deux participants sont disponibles sur le r\u00e9seau (\u00e0 condition que le protocole de consensus utilis\u00e9 soit viable en tenant compte d'un si petit nombre de participants).<\/p>\n
    La plus grande difficult\u00e9 de cette approche r\u00e9side dans la configuration d'un VDF de mani\u00e8re \u00e0 ce qu'un participant disposant de mat\u00e9riel sp\u00e9cialis\u00e9 tr\u00e8s co\u00fbteux ne puisse pas calculer le VDF avant la fin de la phase de divulgation. Id\u00e9alement, l'algorithme devrait avoir m\u00eame une marge de s\u00e9curit\u00e9 significative, disons 10x. La figure ci-dessous montre l'attaque d'un participant ayant un ASIC sp\u00e9cialis\u00e9, ce qui lui permet d'ex\u00e9cuter le VDF plus rapidement que le temps allou\u00e9 pour la divulgation de la confirmation RANDAO. Un tel participant pourrait toujours calculer le r\u00e9sultat final en utilisant ou non son nombre, puis, en se basant sur les calculs, choisir de le montrer ou non.<\/p>\n
    \"Peut-on<\/p>\n
    Pour la famille de VDF mentionn\u00e9e ci-dessus, la performance d'un ASIC sp\u00e9cialis\u00e9 peut \u00eatre plus de 100 fois sup\u00e9rieure \u00e0 celle d'un \u00e9quipement ordinaire. Ainsi, si la phase de divulgation dure 10 secondes, un VDF calcul\u00e9 sur un tel ASIC doit prendre plus de 100 secondes pour avoir une marge de s\u00e9curit\u00e9 de 10 fois, et donc le m\u00eame VDF, calcul\u00e9 sur un \u00e9quipement ordinaire, doit prendre 100 x 100 secondes = ~ 3 heures.<\/p>\n
    La Fondation Ethereum pr\u00e9voit de r\u00e9soudre ce probl\u00e8me en cr\u00e9ant ses propres ASIC publics et gratuits. D\u00e8s que cela se produira, tous les autres protocoles pourront \u00e9galement profiter de cette technologie, mais jusqu'\u00e0 ce moment-l\u00e0, l'approche RANDAO + VDF ne sera pas aussi viable pour les protocoles qui ne peuvent pas investir dans le d\u00e9veloppement de leurs propres ASIC.<\/p>\n
    De nombreux articles, vid\u00e9os et autres informations sur le VDF ont \u00e9t\u00e9 rassembl\u00e9s sur ce site<\/u><\/a><\/noindex>.<\/p>\n
    Utilisation des codes d'effacement<\/h3>\n
    Dans cette section, nous examinerons le protocole de g\u00e9n\u00e9ration de nombres al\u00e9atoires qui utilise des codes d'effacement<\/a><\/noindex>. Il peut supporter jusqu'\u00e0 \u2153 d'agresseurs tout en restant viable, et permet l'existence de jusqu'\u00e0 \u2154 d'agresseurs avant qu'ils ne puissent pr\u00e9dire ou influencer le r\u00e9sultat.<\/p>\n
    L'id\u00e9e principale du protocole est la suivante. Pour simplifier, supposons qu'il ait exactement 100 participants. Supposons aussi que tous les participants aient localement une certaine cl\u00e9 priv\u00e9e, et que les cl\u00e9s publiques de tous les participants soient connues de tous :<\/p>\n
      \n
    1. \n
      Chaque participant invente localement une longue cha\u00eene, la divise en 67 parties, cr\u00e9e des codes d'effacement pour obtenir 100 parts, dont 67 suffisent pour reconstruire la cha\u00eene, attribue chacune des 100 parts \u00e0 un participant et les chiffre avec la cl\u00e9 publique du m\u00eame participant. Ensuite, toutes les parts cod\u00e9es sont publi\u00e9es.<\/p>\n<\/li>\n
    2. \n
      Les participants utilisent un certain consensus pour parvenir \u00e0 un accord sur les ensembles cod\u00e9s de 67 participants sp\u00e9cifiques.<\/p>\n<\/li>\n
    3. \n
      Une fois le consensus atteint, chaque participant prend les parts cod\u00e9es dans chacun des 67 ensembles, chiffr\u00e9es avec leur cl\u00e9 publique, d\u00e9chiffre toutes ces parts et publie toutes ces parts d\u00e9chiffr\u00e9es.<\/p>\n<\/li>\n
    4. \n
      Une fois que 67 participants ont ex\u00e9cut\u00e9 l'\u00e9tape (3), tous les ensembles convenus peuvent \u00eatre compl\u00e8tement d\u00e9cod\u00e9s et reconstruits gr\u00e2ce aux propri\u00e9t\u00e9s des codes d'effacement, et le nombre final peut \u00eatre obtenu comme XOR des cha\u00eenes initiales dont les participants ont commenc\u00e9 en (1).<\/p>\n<\/li>\n<\/ol>\n
      \"Peut-on<\/p>\n
      Il est possible de montrer que ce protocole est impartial et impr\u00e9visible. Le nombre al\u00e9atoire r\u00e9sultant est d\u00e9termin\u00e9 apr\u00e8s l'atteinte du consensus, mais il est inconnu pour tous tant que \u2154 des participants n'ont pas d\u00e9crypt\u00e9 les parties chiffr\u00e9es avec leur cl\u00e9 publique. Ainsi, le nombre al\u00e9atoire est d\u00e9fini avant que l'information n\u00e9cessaire \u00e0 sa r\u00e9cup\u00e9ration ne soit publi\u00e9e.<\/p>\n
      Que se passe-t-il si, \u00e0 l'\u00e9tape (1), l'un des participants envoie aux autres participants des parts cod\u00e9es qui ne constituent pas un code d'effacement correct pour une certaine cha\u00eene ? Sans modifications suppl\u00e9mentaires, des participants diff\u00e9rents ne pourront soit pas r\u00e9cup\u00e9rer la cha\u00eene du tout, soit r\u00e9cup\u00e9rer des cha\u00eenes diff\u00e9rentes, ce qui entra\u00eenera des nombres al\u00e9atoires diff\u00e9rents pour chaque participant. Pour \u00e9viter cela, il est possible de faire ce qui suit : chaque participant, en plus des parts cod\u00e9es, calcule \u00e9galement un arbre de Merkle<\/a><\/noindex> , toutes ces parts, et envoie \u00e0 chaque participant \u00e0 la fois sa part cod\u00e9e et la racine de l'arbre de Merkle, ainsi que la preuve de l'inclusion de la part dans l'arbre de Merkle. Au consensus \u00e0 l'\u00e9tape (2), les participants ne se mettent alors pas seulement d'accord sur plusieurs ensembles, mais sur plusieurs racines sp\u00e9cifiques de ces arbres (si un participant s'\u00e9carte du protocole et envoie diff\u00e9rentes racines d'arbre de Merkle \u00e0 diff\u00e9rents participants, et que deux de ces racines sont montr\u00e9es durant le consensus, sa cha\u00eene n'est pas incluse dans l'ensemble r\u00e9sultant). \u00c0 la fin du consensus, nous aurons 67 cha\u00eenes cod\u00e9es et leurs racines d'arbre de Merkle correspondantes, de sorte qu'il y a au moins 67 participants (pas n\u00e9cessairement les m\u00eames qui ont propos\u00e9 les cha\u00eenes correspondantes), ayant pour chacune des 67 cha\u00eenes un message avec une part de code d'effacement, et une preuve de l'inclusion de leur part dans l'arbre de Merkle correspondant.<\/p>\n
      Lorsque, \u00e0 l'\u00e9tape (4), un participant d\u00e9chiffre 67 parts pour une certaine cha\u00eene, et tente de reconstruire la cha\u00eene originale \u00e0 partir de celles-ci, l'une des options possibles est :<\/p>\n
        \n
      1. \n
        La cha\u00eene est reconstruite, et si elle est ensuite cod\u00e9e \u00e0 nouveau avec des codes d'effacement, et que l'arbre de Merkle est calcul\u00e9 pour les parts calcul\u00e9es localement, la racine correspond \u00e0 celle sur laquelle le consensus a \u00e9t\u00e9 atteint.<\/p>\n<\/li>\n
      2. \n
        La cha\u00eene est reconstruite, mais la racine calcul\u00e9e localement ne correspond pas \u00e0 celle sur laquelle le consensus a \u00e9t\u00e9 atteint.<\/p>\n<\/li>\n
      3. \n
        La cha\u00eene n'est pas reconstruite.<\/p>\n<\/li>\n<\/ol>\n
        Il est facile de montrer que si au moins un participant a rencontr\u00e9 l'option (1), alors tous les participants rencontreront l'option (1), et inversement, si au moins un participant a rencontr\u00e9 l'option (2) ou (3), alors tous les participants rencontreront l'option (2) ou (3). Ainsi, pour chaque ligne dans l'ensemble, soit tous les participants parviennent \u00e0 la restaurer, soit aucun participant ne peut la restaurer. Ensuite, le nombre al\u00e9atoire r\u00e9sultant est le XOR uniquement des lignes que les participants ont r\u00e9ussi \u00e0 restaurer.<\/p>\n
        Signatures de seuil<\/h3>\n
        Une autre approche \u00e0 la randomisation consiste \u00e0 utiliser ce que l'on appelle des signatures de seuil BLS. Un g\u00e9n\u00e9rateur de nombres al\u00e9atoires bas\u00e9 sur des signatures de seuil poss\u00e8de exactement les m\u00eames garanties que l'algorithme d\u00e9crit ci-dessus bas\u00e9 sur des codes effa\u00e7ables, mais a une asymptotique du nombre de messages \u00e9chang\u00e9s sur le r\u00e9seau pour chaque nombre g\u00e9n\u00e9r\u00e9 beaucoup plus faible.<\/p>\n
        Les signatures BLS sont une construction qui permet \u00e0 plusieurs participants de cr\u00e9er une signature commune pour un message. De telles signatures sont souvent utilis\u00e9es pour \u00e9conomiser de l'espace et de la bande passante, car elles ne n\u00e9cessitent pas l'envoi de plusieurs signatures. <\/p>\n
        Une application fr\u00e9quente des signatures BLS dans les protocoles blockchain, en plus de la g\u00e9n\u00e9ration de nombres al\u00e9atoires, est la signature de blocs dans les protocoles BFT. Par exemple, 100 participants cr\u00e9ent des blocs, et un bloc est consid\u00e9r\u00e9 comme final si 67 d'entre eux le signent. Tous peuvent pr\u00e9senter leurs parties de la signature BLS et utiliser un certain algorithme de consensus pour convenir de 67 d'entre eux, puis les combiner en une seule signature BLS. N'importe quelles 67 (ou plus) parties peuvent \u00eatre utilis\u00e9es pour cr\u00e9er la signature finale, qui d\u00e9pend des 67 signatures sp\u00e9cifiques qui ont \u00e9t\u00e9 combin\u00e9es et peut donc varier, mais malgr\u00e9 le fait qu'un choix diff\u00e9rent de 67 participants produira une signature diff\u00e9rente, toute signature de ce type sera une signature valide pour le bloc. Les autres participants n'ont alors qu'\u00e0 recevoir et v\u00e9rifier uniquement une signature par bloc, et non pas 67, ce qui r\u00e9duit consid\u00e9rablement la charge sur le r\u00e9seau.<\/p>\n
        Il s'av\u00e8re que si les cl\u00e9s priv\u00e9es utilis\u00e9es par les participants sont g\u00e9n\u00e9r\u00e9es d'une certaine mani\u00e8re, peu importe quelles 67 signatures (ou plus, mais pas moins) sont agr\u00e9g\u00e9es, la signature r\u00e9sultante sera identique. Cela peut \u00eatre utilis\u00e9 comme source d'al\u00e9a : les participants conviennent d'abord d'un certain message qu'ils signeront (cela peut \u00eatre le r\u00e9sultat de RANDAO ou simplement le hachage du dernier bloc, en fait cela n'a pas d'importance tant que cela change \u00e0 chaque fois et est consensuel), et cr\u00e9ent une signature BLS pour celui-ci. Le r\u00e9sultat de la g\u00e9n\u00e9ration sera impr\u00e9visible tant que 67 participants n'auront pas fourni leurs parts, et apr\u00e8s cela, les r\u00e9sultats sont d\u00e9j\u00e0 pr\u00e9d\u00e9finis et ne peuvent pas d\u00e9pendre des actions d'un participant.<\/p>\n
        Cette approche de l'al\u00e9a est viable tant qu'au moins \u2154 des participants sont en ligne et suivent le protocole, et elle est impartiale et impr\u00e9visible tant qu'au moins \u2153 des participants respectent le protocole. Il est important de noter qu'un attaquant qui contr\u00f4le plus d'un tiers mais moins des deux tiers des participants peut arr\u00eater le protocole, mais ne peut pas pr\u00e9voir ou influencer son r\u00e9sultat.<\/p>\n
        Les signatures de seuil en elles-m\u00eames sont un sujet tr\u00e8s int\u00e9ressant. Dans la deuxi\u00e8me partie de cet article, nous examinerons en d\u00e9tail comment elles fonctionnent et comment il est n\u00e9cessaire de g\u00e9n\u00e9rer les cl\u00e9s des participants pour que les signatures de seuil puissent \u00eatre utilis\u00e9es comme g\u00e9n\u00e9rateur de nombres al\u00e9atoires.<\/p>\n
        En conclusion<\/h3>\n
        Cet article est le premier d'une s\u00e9rie d'articles techniques sur le blog NEAR<\/a><\/noindex>. NEAR est un protocole blockchain et une plateforme pour le d\u00e9veloppement d'applications d\u00e9centralis\u00e9es mettant l'accent sur la simplicit\u00e9 de d\u00e9veloppement et la facilit\u00e9 d'utilisation pour les utilisateurs finaux.<\/p>\n
        Le code du protocole est ouvert, notre impl\u00e9mentation est \u00e9crite en Rust, et elle peut \u00eatre trouv\u00e9e ici<\/a><\/noindex>.<\/p>\n
        Vous pouvez voir \u00e0 quoi ressemble le d\u00e9veloppement sous NEAR et exp\u00e9rimenter dans l'IDE en ligne ici<\/a><\/noindex>.<\/p>\n
        Pour suivre toutes les nouvelles en russe, vous pouvez visiter le groupe sur Telegram<\/a><\/noindex> et dans groupe sur VKontakte.<\/a><\/noindex>, et en anglais sur le site officiel Twitter<\/a><\/noindex>.<\/p>\n
        \u00c0 bient\u00f4t !<\/p>\n
        Source : habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
        \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043f\u0440\u043e \u0433\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u044e \u043f\u0441\u0435\u0432\u0434\u043e-\u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u044e\u0442 \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443. \u041a\u0430\u043a \u043c\u044b \u0443\u0432\u0438\u0434\u0438\u043c \u043d\u0438\u0436\u0435, \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u0442\u044c \u201c\u043f\u043e\u0447\u0442\u0438\u201d \u0445\u043e\u0440\u043e\u0448\u0438\u0439 \u0433\u0435\u043d\u0435\u0440\u0430\u0442\u043e\u0440 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043f\u0440\u043e\u0441\u0442\u043e, \u0430 \u0432\u043e\u0442 \u043e\u0447\u0435\u043d\u044c \u0445\u043e\u0440\u043e\u0448\u0438\u0439 \u2013 \u0441\u043b\u043e\u0436\u043d\u043e. \u0417\u0430\u0447\u0435\u043c \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0443\u0436\u043d\u043e \u0433\u0435\u043d\u0435\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c, \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u044e\u0449\u0438\u043c \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443? \u041e\u0434\u043d\u0430 \u0438\u0437 \u043e\u0431\u043b\u0430\u0441\u0442\u0435\u0439 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044f — \u044d\u0442\u043e \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435, \u043a\u043e\u0442\u043e\u0440\u043e\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":95469,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-95468","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Est-il possible de g\u00e9n\u00e9rer des nombres al\u00e9atoires si nous ne nous faisons pas confiance ? Partie 1 | ProHoster","description":"Bonjour, Habr ! Dans cet article, je vais parler de la g\u00e9n\u00e9ration de nombres pseudo-al\u00e9atoires par des participants qui ne se fient pas les uns aux autres.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041c\u043e\u0436\u043d\u043e \u043b\u0438 \u0433\u0435\u043d\u0435\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430, \u0435\u0441\u043b\u0438 \u043c\u044b \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u0435\u043c \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443? \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440!\u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043f\u0440\u043e \u0433\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u044e \u043f\u0441\u0435\u0432\u0434\u043e-\u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u044e\u0442 \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-09-29T17:42:29+00:00","article:modified_time":"2020-09-29T17:42:29+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"95468","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:05:29","updated":"2022-09-28 01:55:15","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/95468","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=95468"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/95468\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/95469"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=95468"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=95468"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=95468"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}