Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Stefan Wiens Newsgroups: de.sci.electronics Subject: Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Date: Sun, 27 Sep 2026 13:50:45 +0200 Organization: none Lines: 53 Message-ID: <87o6dincha.fsf@s-bot.de> References: <118kj9q$gqv2$1@solani.org> <118ks8h$elv8$1@solani.org> <874iflsqhd.fsf@s-bot.de> <118rmr7$4mf6$1@solani.org> <118rsru$2psp$1@solani.org> <118rtau$4rpv$1@solani.org> <118s1ov$2t65$1@solani.org> <118s25u$4v9f$1@solani.org> <118s2pp$2u1a$1@solani.org> <118sf0g$587h$1@solani.org> <118tsn4$6al2$1@solani.org> <118u56h$73r4$1@gwaiyur.mb-net.net> <1191ful$8u69$1@solani.org> <1193rff$870n$1@solani.org> <1195te7$9ice$1@solani.org> <1196o6a$cq76$1@solani.org> <1197a6f$d604$1@solani.org> <1198ig0$bca7$1@solani.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: individual.net OaCmN+8go/SG1Uf7KTTZPwS6gGhJJwFJteDHYGPzc0xrLH+sU= Cancel-Lock: sha1:k1Al7vxu7hVeHe0iMFW3r7uUFlk= sha1:7Ts1J3ZEbYLyoFGXgi1K8xOaJMA= sha256:9KZqdlV3a2M6wdtQnbuyBE3LgtAYskAaslw86RrrAek= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Xref: csiph.com de.sci.electronics:369593 Helmut Schellong writes: > Leo Baumann wrote on 26.09.2026 04:20: >> Am 25.09.2026 um 23:13 schrieb Helmut Schellong: >>> Ich konnte den Zeitbedarf des Kommandos 'randtsc' von etwa 1,5 h auf 50 s/MB senken. >>> Das sind etwa 1,7 GB pro Tag, bei einem CPU-Kern. >>> Die Qualität konnte ich durch Verringern der Bitbreite halten - immer noch 0 NIST-Fehler. >>> Der Mittelwert der p_values ist im Überblick geringer. >>> Der übergroße Hub zuvor hatte durchaus eine positive Wirkung auf die Qualität. >>> >>> Das Projekt ist nun vorläufig beendet. >>> Ich kann das Kommando nun normal nutzen. >>> >>> >>> Es sind wirklich echte Zufallszahlen! >>> Die erste vom Kommando gelesene Zahl ist sowieso eine echte Zufallszahl. >>> Diese echte Zufallszahl bestimmt hauptsächlich die Dauer der Kommando- Verzögerung. >>> Folglich ist die nächste gelesene Zahl erneut eine echte Zufallszahl, usw. >>> >>> Zudem beaufschlagt die gesamte Hardware+Software des Computers dem Kommando Verzögerungen. >>> Diese addieren sich zu der internen Verzögerung des Kommandos, und sie können größer sein >>> als die interne Verzögerung des Kommandos. >>> Es sind entsprechende Veränderungen an den ausgegebenen Differenzen und der geregelten >>> Bitbreite erkennbar und eindeutig zuzuordnen. >>> >>> Das Kommando ist nicht deterministisch in Bezug auf die gelesenen TSC- Werte. >>> Ich kann jeglichen Ausgabe-Strom nicht gezielt wiederholen, alle längeren sind >>> tendenziell einzigartig. >> Für welchen Einsatzbereich planst du diesen Zufallsgenerator?Für ein >> Spiel oder eine Simulation (wo Performance wichtig ist und >> Algorithmen wie Xorshift oder Mersenne-Twister perfekt sind)? >> Für ein Sicherheitsprojekt / Kryptografie (wo PRNGs mit RDTSC-Seed >> tabu sind und man stattdessen RDRAND oder Betriebssystem-Entropie >> wie /dev/urandom nutzen muss)? > > Ich verfolge damit das Konzept 'One-Time-Pad'. > Ich muß dann nicht meine Archiv-Dateien (bis 6 GB) mehrfach mit PRNGs > verschlüsseln, sondern verwende ein 10 GB großes Pad, mit dem ich > meine Archive per XOR verknüpfe: v = a xor p > > In dem Pad befinden sich echte Zufallszahlen höchster Qualität. > Ich brauche dann immer nur das fertige Pad mit wechselnden Offsets, keinen Generator mehr. > Die Verschlüsselung läuft dann rasend schnell. Irgendwie klingt das so, als sollte der "perfekte" OTP mit variablen Offsets mehrfach verwendet werden. Bei so einer Herangehensweise lässt sich oft schon aus zwei längeren Ciphertexts der Schlüssel regenerieren. -- Stefan