{"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\/de\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","title":{"rendered":"Kann man Zufallszahlen generieren, wenn wir uns nicht gegenseitig vertrauen? Teil 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, Habra!<\/p>\n

In diesem Artikel werde ich die Erzeugung von Pseudo-Zufallszahlen durch Teilnehmer erl\u00e4utern, die einander nicht vertrauen. Wie wir gleich sehen werden, ist es relativ einfach, einen \u201efast\u201c guten Generator zu implementieren, aber einen sehr guten zu erstellen, ist kompliziert.<\/p>\n

Warum m\u00fcssen Teilnehmer, die einander nicht vertrauen, \u00fcberhaupt Zufallszahlen generieren? Ein Anwendungsbereich sind dezentrale Anwendungen. Zum Beispiel wird eine App, die einen Einsatz von einem Teilnehmer entgegennimmt und entweder die Summe mit einer Wahrscheinlichkeit von 49 % verdoppelt oder sie mit 51 % einbehalten kann, nur funktionieren, wenn sie unparteiisch eine Zufallszahl erhalten kann. Wenn ein Angreifer den Ausgang des Zufallszahlengenerators beeinflussen kann und sogar seine Chancen, eine Auszahlung in der App zu erhalten, geringf\u00fcgig erh\u00f6hen kann, wird er sie leicht ausrauben.<\/p>\n

Wenn wir ein verteiltes Protokoll zur Generierung von Zufallszahlen entwickeln, wollen wir, dass es drei Eigenschaften hat:<\/p>\n

    \n
  1. \n

    Es muss unparteiisch sein. Mit anderen Worten, kein Teilnehmer darf auf irgendeine Weise das Ergebnis des Zufallszahlengenerators beeinflussen.<\/p>\n<\/li>\n

  2. \n

    Es muss unvorhersehbar sein. Mit anderen Worten, kein Teilnehmer darf in der Lage sein vorherzusagen, welche Zahl generiert wird (oder irgendwelche ihrer Eigenschaften herauszufinden), bevor sie generiert wird.<\/p>\n<\/li>\n

  3. \n

    Das Protokoll muss funktionsf\u00e4hig sein, das hei\u00dft, es muss widerstandsf\u00e4hig gegen das Ausfallen eines bestimmten Prozentsatzes von Teilnehmern oder gegen absichtliche Versuche sein, das Protokoll zu stoppen.<\/p>\n<\/li>\n<\/ol>\n

    In diesem Artikel werden wir zwei Ans\u00e4tze betrachten: RANDAO + VDF und den Ansatz, der auf L\u00f6schcodes basiert. Im n\u00e4chsten Teil werden wir den auf Schwellenwertsignaturen basierenden Ansatz ausf\u00fchrlich erl\u00e4utern.<\/p>\n

    Aber zuerst schauen wir uns einen einfachen und h\u00e4ufig verwendeten Algorithmus an, der funktionsf\u00e4hig, unvorhersehbar, aber voreingenommen ist.<\/p>\n

    RANDAO<\/h3>\n

    RANDAO ist ein sehr einfacher und daher ziemlich h\u00e4ufig verwendeter Ansatz zur Generierung von Zuf\u00e4lligkeit. Alle Teilnehmer im Netzwerk w\u00e4hlen zun\u00e4chst lokal eine pseudorandomisierte Zahl, dann sendet jeder Teilnehmer den Hash der gew\u00e4hlten Zahl. Anschlie\u00dfend decken die Teilnehmer nacheinander ihre gew\u00e4hlten Zahlen auf und f\u00fchren eine XOR-Operation an den aufgedeckten Zahlen durch, wobei das Ergebnis dieser Operation das Ergebnis des Protokolls darstellt.<\/p>\n

    Der Schritt zur Ver\u00f6ffentlichung der Hashes, bevor die Zahlen aufgedeckt werden, ist notwendig, damit ein Angreifer seine Zahl nicht ausw\u00e4hlen kann, nachdem er die Zahlen der anderen Teilnehmer gesehen hat. Dies w\u00fcrde es ihm erm\u00f6glichen, das Ergebnis des Zufallszahlengenerators faktisch allein zu bestimmen.<\/p>\n

    Im Verlauf des Protokolls m\u00fcssen die Teilnehmer zweimal zu einer gemeinsamen Entscheidung (dem sogenannten Konsens) kommen: wann sie beginnen, die gew\u00e4hlten Zahlen aufzudecken, und damit aufh\u00f6ren, Hashes zu akzeptieren, und wann sie aufh\u00f6ren, die gew\u00e4hlten Zahlen zu akzeptieren und die resultierende Zufallszahl zu berechnen. Die Entscheidungsfindung zwischen Teilnehmern, die sich gegenseitig nicht vertrauen, ist an sich eine schwierige Aufgabe, und wir werden in zuk\u00fcnftigen Artikeln darauf zur\u00fcckkommen; in diesem Artikel gehen wir davon aus, dass uns ein solcher Konsensalgorithmus zur Verf\u00fcgung steht.<\/p>\n

    Welche der oben beschriebenen Eigenschaften hat RANDAO? Es ist unvorhersehbar, hat die gleiche Lebensf\u00e4higkeit wie das zugrunde liegende Konsensprotokoll, ist aber voreingenommen. Insbesondere kann ein Angreifer das Netzwerk beobachten, und nachdem andere Teilnehmer ihre Zahlen aufgedeckt haben, kann er deren XOR berechnen und entscheiden, ob er seine eigene Zahl aufdecken oder nicht aufdecken m\u00f6chte, um das Ergebnis zu beeinflussen. W\u00e4hrend es dem Angreifer nicht erlaubt, das Ergebnis des Zufallszahlengenerators allein zu bestimmen, gibt es ihm dennoch 1 Bit Einfluss. Und wenn Angreifer mehrere Teilnehmer kontrollieren, entspricht die Anzahl der von ihnen kontrollierten Bits der Anzahl der Teilnehmer unter ihrer Kontrolle.<\/p>\n

    \"Kann<\/p>\n

    Der Einfluss der Angreifer kann erheblich reduziert werden, wenn gefordert wird, dass die Teilnehmer die Zahlen der Reihe nach aufdecken. Dann kann der Angreifer das Ergebnis nur beeinflussen, wenn er zuletzt aufgedeckt wird. W\u00e4hrend der Einfluss deutlich geringer ist, bleibt der Algorithmus dennoch voreingenommen.<\/p>\n

    RANDAO + VDF<\/h3>\n

    Eine der M\u00f6glichkeiten, RANDAO uneingeschr\u00e4nkt zu machen, besteht darin, dass, nachdem alle Zahlen aufgedeckt und das XOR berechnet wurde, das Ergebnis an eine Funktion \u00fcbergeben wird, die eine sehr lange Zeit ben\u00f6tigt, um berechnet zu werden, es aber erm\u00f6glicht, die Richtigkeit der Berechnung sehr schnell zu \u00fcberpr\u00fcfen.<\/p>\n

    (vdf_output, vdf_proof) = VDF_compute(input) \/\/ das ist sehr langsam\ncorrect = VDF_verify(input, vdf_output, vdf_proof) \/\/ das ist sehr schnell<\/code><\/pre>\n
    Diese Funktion wird als Verifiable Delay Function oder VDF bezeichnet. Wenn die Berechnung des endg\u00fcltigen Ergebnisses l\u00e4nger dauert als die Phase der Offenlegung der Zahlen, kann ein Angreifer den Effekt der Demonstration oder des Versteckens seiner Zahl nicht vorhersagen, und verliert somit die M\u00f6glichkeit, das Ergebnis zu beeinflussen.<\/p>\n
    Die Entwicklung guter VDF ist extrem kompliziert. In letzter Zeit gab es mehrere Durchbr\u00fcche, zum Beispiel diesen<\/u><\/a><\/noindex> und dieser,<\/u><\/a><\/noindex> die VDF praktischer anwendbar gemacht haben, und Ethereum 2.0 plant langfristig, RANDAO mit VDF als Quelle f\u00fcr Zufallszahlen zu verwenden. Neben der Tatsache, dass dieser Ansatz unvorhersehbar und unbefangen ist, hat er den zus\u00e4tzlichen Vorteil der Lebensf\u00e4higkeit, solange mindestens zwei Teilnehmer im Netzwerk verf\u00fcgbar sind (vorausgesetzt, dass das verwendete Konsensprotokoll auch bei so wenigen Teilnehmern funktioniert).<\/p>\n
    Die gr\u00f6\u00dfte Herausforderung dieses Ansatzes besteht darin, eine VDF so einzurichten, dass selbst ein Teilnehmer mit sehr teurer spezialisierter Hardware die VDF nicht vor dem Ende der Offenlegungsphase berechnen kann. Idealerweise sollte der Algorithmus sogar einen bedeutenden Sicherheitsabstand haben, sagen wir 10-fach. Die folgende Abbildung zeigt einen Angriff eines Teilnehmers, der \u00fcber einen spezialisierten ASIC verf\u00fcgt, der es ihm erm\u00f6glicht, die VDF schneller auszuf\u00fchren als die f\u00fcr die Offenlegung der RANDAO-Best\u00e4tigung vorgesehene Zeit. Ein solcher Teilnehmer kann weiterhin das endg\u00fcltige Ergebnis sowohl mit als auch ohne seine Zahl berechnen und anschlie\u00dfend basierend auf diesen Berechnungen entscheiden, ob er sie zeigt oder nicht.<\/p>\n
    \"Kann<\/p>\n
    F\u00fcr das vorgenannte Familienspektrum an VDF kann die Leistung spezialisierter ASICs mehr als 100-mal h\u00f6her sein als die von herk\u00f6mmlicher Hardware. Wenn die Offenlegungsphase also 10 Sekunden dauert, m\u00fcsste die auf einem solchen ASIC berechnete VDF mehr als 100 Sekunden in Anspruch nehmen, um einen 10-fachen Sicherheitsabstand zu haben. Daher m\u00fcsste dieselbe VDF, die auf herk\u00f6mmlicher Hardware berechnet wird, 100 x 100 Sekunden = ~ 3 Stunden dauern.<\/p>\n
    Die Ethereum Foundation plant, dieses Problem durch die Schaffung eigener \u00f6ffentlicher kostenloser ASIC zu l\u00f6sen. Sobald dies geschieht, k\u00f6nnen auch alle anderen Protokolle von dieser Technologie profitieren, aber bis dahin wird der Ansatz RANDAO + VDF f\u00fcr Protokolle, die nicht in die Entwicklung eigener ASIC investieren k\u00f6nnen, nicht genauso tragf\u00e4hig sein.<\/p>\n
    Es gibt viele Artikel, Videos und andere Informationen \u00fcber VDF, die gesammelt wurden auf dieser Website<\/u><\/a><\/noindex>.<\/p>\n
    Wir verwenden L\u00f6schen-Codes<\/h3>\n
    In diesem Abschnitt betrachten wir das Protokoll zur Generierung von Zufallszahlen, das L\u00f6schen-Codes<\/a><\/noindex>. Es kann bis zu \u2153 der Angreifer \u00fcberstehen und erm\u00f6glicht die Existenz von bis zu \u2154 Angreifern, bevor sie das Ergebnis vorhersagen oder beeinflussen k\u00f6nnen.<\/p>\n
    Die Grundidee des Protokolls ist folgende: Zum Einfachheit nehmen wir an, dass es genau 100 Teilnehmer gibt. Angenommen, jeder Teilnehmer hat lokal einen privaten Schl\u00fcssel, und die \u00f6ffentlichen Schl\u00fcssel aller Teilnehmer sind allen Teilnehmern bekannt:<\/p>\n
      \n
    1. \n
      Jeder Teilnehmer denkt sich lokal eine lange Zeichenkette aus, teilt sie in 67 Teile und erstellt L\u00f6schen-Codes, um 100 Anteile zu erhalten, wobei beliebige 67 zur Wiederherstellung der Zeichenkette ausreichen, weist jeder der 100 Anteile einem der Teilnehmer zu und verschl\u00fcsselt sie mit dem \u00f6ffentlichen Schl\u00fcssel desselben Teilnehmers. Dann werden alle codierten Anteile ver\u00f6ffentlicht.<\/p>\n<\/li>\n
    2. \n
      Die Teilnehmer verwenden einen Konsens, um sich \u00fcber die codierten S\u00e4tze von bestimmten 67 Teilnehmern zu einigen.<\/p>\n<\/li>\n
    3. \n
      Sobald Konsens erreicht ist, nimmt jeder Teilnehmer die codierten Anteile in jedem der 67 S\u00e4tze, die mit ihrem \u00f6ffentlichen Schl\u00fcssel verschl\u00fcsselt sind, entschl\u00fcsselt alle derartigen Anteile und ver\u00f6ffentlicht alle dieser entschl\u00fcsselten Anteile.<\/p>\n<\/li>\n
    4. \n
      Sobald 67 Teilnehmer Schritt (3) ausgef\u00fchrt haben, k\u00f6nnen alle vereinbarten S\u00e4tze aufgrund der Eigenschaften der L\u00f6schen-Codes vollst\u00e4ndig decodiert und wiederhergestellt werden, und die endg\u00fcltige Zahl kann als XOR der urspr\u00fcnglichen Zeichenketten, mit denen die Teilnehmer in (1) begonnen haben, erhalten werden.<\/p>\n<\/li>\n<\/ol>\n
      \"Kann<\/p>\n
      Es kann gezeigt werden, dass dieses Protokoll unparteiisch und unvorhersehbar ist. Die resultierende Zufallszahl wird nach Erreichung eines Konsenses bestimmt, aber niemand wei\u00df davon, bis \u2154 der Teilnehmer die Teile, die mit ihrem \u00f6ffentlichen Schl\u00fcssel verschl\u00fcsselt sind, dekodieren. So wird die Zufallszahl vorher bestimmt, bevor die Informationen, die f\u00fcr ihre Wiederherstellung notwendig sind, ver\u00f6ffentlicht werden.<\/p>\n
      Was passiert, wenn in Schritt (1) einer der Teilnehmer den anderen Teilnehmern kodierte Anteile sendet, die keinen korrekten L\u00f6schcode einer bestimmten Zeichenfolge darstellen? Ohne zus\u00e4tzliche \u00c4nderungen werden verschiedene Teilnehmer entweder die Zeichenfolge gar nicht wiederherstellen k\u00f6nnen oder unterschiedliche Zeichenfolgen wiederherstellen, was dazu f\u00fchrt, dass verschiedene Teilnehmer unterschiedliche Zufallszahlen erhalten. Um dies zu verhindern, kann Folgendes gemacht werden: Jeder Teilnehmer berechnet neben den kodierten Anteilen auch Merkelbaum<\/a><\/noindex> , und sendet jedem Teilnehmer sowohl den kodierten Anteil als auch die Wurzel des Merkelbaums sowie einen Beweis f\u00fcr die Einbeziehung des Anteils in den Merkelbaum. Im Konsens in Schritt (2) stimmen die Teilnehmer dann nicht nur \u00fcber eine Reihe von S\u00e4tzen zu, sondern auch \u00fcber eine Reihe konkreter Wurzeln solcher B\u00e4ume (wenn ein Teilnehmer vom Protokoll abweicht und unterschiedliche Wurzeln des Merkelbaums an verschiedene Teilnehmer sendet und zwei solcher Wurzeln im Konsens gezeigt werden, wird seine Zeichenfolge nicht in das Ergebnisset aufgenommen). Am Ende des Konsenses haben wir 67 kodierte Zeichenfolgen und die entsprechenden Wurzeln des Merkelbaums, sodass es mindestens 67 Teilnehmer gibt (nicht unbedingt dieselben, die die entsprechenden Zeichenfolgen vorgeschlagen haben), f\u00fcr die f\u00fcr jede der 67 Zeichenfolgen eine Nachricht mit einem Anteil des L\u00f6schcodes und ein Beweis der Einbeziehung ihres Anteils in den entsprechenden Merkelbaum vorhanden ist.<\/p>\n
      Wenn ein Teilnehmer in Schritt (4) 67 Anteile f\u00fcr eine bestimmte Zeichenfolge dekodiert und versucht, die urspr\u00fcngliche Zeichenfolge wiederherzustellen, kann Folgendes geschehen:<\/p>\n
        \n
      1. \n
        Die Zeichenfolge wird wiederhergestellt, und wenn sie dann erneut mit L\u00f6schcodes kodiert und der Merkelbaum f\u00fcr die lokal berechneten Anteile gez\u00e4hlt wird, stimmt die Wurzel mit der \u00fcberein, bei der der Konsens erreicht wurde.<\/p>\n<\/li>\n
      2. \n
        Die Zeichenfolge wird wiederhergestellt, aber die lokal berechnete Wurzel stimmt nicht mit der \u00fcberein, bei der der Konsens erreicht wurde.<\/p>\n<\/li>\n
      3. \n
        Die Zeichenfolge kann nicht wiederhergestellt werden.<\/p>\n<\/li>\n<\/ol>\n
        Es ist leicht zu zeigen, dass, wenn f\u00fcr mindestens einen Teilnehmer die Variante (1) aufgetreten ist, f\u00fcr alle Teilnehmer die Variante (1) auftritt, und umgekehrt, wenn f\u00fcr mindestens einen Teilnehmer die Variante (2) oder (3) aufgetreten ist, dann tritt f\u00fcr alle Teilnehmer die Variante (2) oder (3) auf. Somit wird f\u00fcr jede Zeile in der Menge entweder allen Teilnehmern gelingen, sie erfolgreich wiederherzustellen, oder es wird allen Teilnehmern nicht gelingen, sie wiederherzustellen. Die resultierende Zufallszahl ist dann das XOR nur jener Zeilen, die die Teilnehmer wiederherstellen konnten.<\/p>\n
        Schwellensignaturen<\/h3>\n
        Ein anderer Ansatz zur Zuf\u00e4lligkeit besteht in der Verwendung von sogenannten BLS-Schwellensignaturen. Ein auf Schwellensignaturen basierender Zufallszahlengenerator hat die gleichen Garantien wie der oben beschriebene Algorithmus, der auf L\u00f6schcodes basiert, hat aber eine erheblich geringere asymptotische Anzahl an Nachrichten, die f\u00fcr jede generierte Zahl \u00fcber das Netzwerk gesendet werden.<\/p>\n
        BLS-Signaturen sind eine Konstruktion, die es mehreren Teilnehmern erm\u00f6glicht, eine gemeinsame Signatur f\u00fcr eine Nachricht zu erstellen. Solche Signaturen werden h\u00e4ufig verwendet, um Platz und Bandbreite zu sparen, da sie die Verbreitung mehrerer Signaturen nicht erfordern. <\/p>\n
        Eine h\u00e4ufige Anwendung von BLS-Signaturen in Blockchain-Protokollen, neben der Generierung von Zufallszahlen, besteht darin, Bl\u00f6cke in BFT-Protokollen zu signieren. Angenommen, 100 Teilnehmer erstellen Bl\u00f6cke, und ein Block wird als endg\u00fcltig betrachtet, wenn 67 von ihnen ihn signieren. Alle k\u00f6nnen ihre Teile der BLS-Signatur vorlegen und einen Konsens-Algorithmus verwenden, um 67 davon zu vereinbaren und sie dann zu einer einzigen BLS-Signatur zusammenzuf\u00fchren. Jedes 67 (oder mehr) Teile k\u00f6nnen zur Erstellung der finalen Signatur verwendet werden, die davon abh\u00e4ngt, welche spezifischen 67 Signaturen kombiniert wurden, und daher variieren kann, aber obwohl die Auswahl von 67 Teilnehmern unterschiedliche Signaturen erzeugt, ist jede dieser Signaturen eine g\u00fcltige Signatur f\u00fcr den Block. Den anderen Teilnehmern reicht es dann aus, \u00fcber das Netzwerk nur eine Signatur f\u00fcr jeden Block zu erhalten und zu \u00fcberpr\u00fcfen, anstatt 67, was die Netzlast erheblich reduziert.<\/p>\n
        Es stellt sich heraus, dass, wenn die privaten Schl\u00fcssel, die von den Teilnehmern verwendet werden, auf eine bestimmte Weise generiert werden, unabh\u00e4ngig davon, welche 67 Signaturen (oder mehr, aber keinesfalls weniger) aggregiert werden, die resultierende Signatur identisch sein wird. Dies kann als Quelle der Zuf\u00e4lligkeit verwendet werden: Die Teilnehmer einigen sich zun\u00e4chst auf eine bestimmte Nachricht, die sie signieren werden (das kann entweder der Ausgang von RANDAO oder einfach der Hash des letzten Blocks sein, tats\u00e4chlich spielt es keine Rolle, solange es sich jedes Mal \u00e4ndert und vereinbart ist), und erstellen daf\u00fcr eine BLS-Signatur. Das Ergebnis der Generierung wird unvorhersehbar sein, bis 67 Teilnehmer ihre Teile bereitstellen, und danach sind die Ausgaben bereits vorbestimmt und k\u00f6nnen nicht von den Handlungen eines einzelnen Teilnehmers abh\u00e4ngen.<\/p>\n
        Dieser Ansatz zur Zuf\u00e4lligkeit ist tragf\u00e4hig, wenn mindestens \u2154 der Teilnehmer online sind und dem Protokoll folgen, und unparteiisch und unvorhersehbar, solange mindestens \u2153 der Teilnehmer dem Protokoll folgen. Es ist wichtig zu beachten, dass ein Angreifer, der mehr als \u2153 aber weniger als \u2154 der Teilnehmer kontrolliert, das Protokoll stoppen kann, aber seine Ausgabe nicht vorhersagen oder beeinflussen kann.<\/p>\n
        Schwellensignaturen sind an sich ein sehr interessantes Thema. Im zweiten Teil des Artikels werden wir im Detail untersuchen, wie sie funktionieren und wie genau die Schl\u00fcssel der Teilnehmer generiert werden m\u00fcssen, damit Schwellensignaturen als Zufallszahlengenerator verwendet werden k\u00f6nnen.<\/p>\n
        Abschlie\u00dfend<\/h3>\n
        Dieser Artikel ist der erste in einer Reihe technischer Artikel im Blog NEAR<\/a><\/noindex>. NEAR ist ein Blockchain-Protokoll und eine Plattform zur Entwicklung dezentralisierter Anwendungen mit Schwerpunkt auf einfacher Entwicklung und Benutzerfreundlichkeit f\u00fcr Endbenutzer.<\/p>\n
        Der Protokollcode ist offen, unsere Implementierung ist in Rust geschrieben, und sie kann gefunden werden hier<\/a><\/noindex>.<\/p>\n
        Sie k\u00f6nnen sehen, wie die Entwicklung unter NEAR aussieht, und in der Online-IDE experimentieren hier<\/a><\/noindex>.<\/p>\n
        Um alle Nachrichten auf Russisch zu verfolgen, k\u00f6nnen Sie in der Gruppe im Telegram<\/a><\/noindex> und in Gruppe auf VKontakte<\/a><\/noindex>, und auf Englisch im offiziellen Twitter-Account<\/a><\/noindex>.<\/p>\n
        Bis bald!<\/p>\n
        Quelle: 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\udd47Kann man Zufallszahlen generieren, wenn wir uns nicht vertrauen? Teil 1 | ProHoster","description":"Hallo, Habr! In diesem Artikel werde ich \u00fcber die Generierung pseudo-zuf\u00e4lliger Zahlen durch Teilnehmer berichten, die sich gegenseitig nicht vertrauen.","canonical_url":"https:\/\/prohoster.info\/de\/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":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/95468","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=95468"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/95468\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/95469"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=95468"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=95468"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=95468"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}