Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Stefan Wiens Newsgroups: de.sci.electronics Subject: Re: random_rdtsc und random_rdrand Date: Sun, 04 Oct 2026 12:46:07 +0200 Organization: none Lines: 62 Message-ID: <87ece5kazt.fsf@s-bot.de> References: <119g637$gnp5$1@solani.org> <119jec5$lqhu$1@solani.org> <119jgm6$j74o$1@solani.org> <119jjb3$luij$1@solani.org> <119jlkk$jb56$1@solani.org> <119jm08$m0k1$1@solani.org> <119jv68$jhg9$1@solani.org> <119k3oe$ma1h$1@solani.org> <119m23p$l012$1@solani.org> <119nbv7$lqst$1@solani.org> <119odhm$mjbe$1@solani.org> <87v77kkx02.fsf@s-bot.de> <87jynzlvty.fsf@s-bot.de> <878q4fkl66.fsf@s-bot.de> <119qvgr$r6sg$1@solani.org> <119r6re$rcdv$1@solani.org> <119r7cv$rclr$1@solani.org> <119s0n7$rv7e$1@solani.org> <87qzi6jljv.fsf@s-bot.de> <119t98e$sqh4$1@solani.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: individual.net Ztd1nDJtZBGYmxcaqWFjtADuMxe8iz3BQ8Wo9y9978X3lrhM0= Cancel-Lock: sha1:Aj5A3F4pw6mlippbmbD8tz/0+kw= sha1:F+ZboXPEsJonGHjqeP+TenMzI0o= sha256:8UMv7Ehybtu2x/8xhv9jExkAExmGg3bY+pxWAwhaFpM= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Xref: csiph.com de.sci.electronics:369723 Helmut Schellong writes: > Stefan Wiens wrote on 04.10.2026 03:41: >> Helmut Schellong writes: >> >>> Leo Baumann wrote on 03.10.2026 17:35: >>>> Am 03.10.2026 um 17:26 schrieb Helmut Schellong: >>>>>> Alle gelesenen TSC-Werte danach nicht. >>>>> >>>>> Doch, weil echt zufällige Verzögerungen durch das Programm randtsc.exe zu ebenso >>>>> echt zufälligen gelesenen Zahlen führen. >>>>> >>>>> Siehe den NIST-Test, der ein solches Lesen des TSC als überlegen gegenüber >>>>> den Instruktionen 'rdrand' und 'rdseed' erklärt. >>>> Der NIST-Test bestätigt *nicht* die Unvorhersehbarkeit und >>>> kryptografische Sicherheit und genau diese beiden sind bei >>>> random_rdtsc *nicht* gegeben. >>> >>> Der NIST-Test bestätigt sehr wohl die kryptographische Sicherheit. >>> Dafür ist er gemacht! >>> Er bestätigt _nicht_ die Unvorhersehbarkeit. >>> >>> Der Algorithmus des 'randtsc' bestätigt allerdings die Unvorhersehbarkeit, weil nur >>> ein kleiner Teil der Bits des TSC zur Nutzung verwendet werden. >>> Es kann auch nur das eine Bit ganz rechts verwendet werden, wenn man will (LSB). >>> Eines von 64. >>> Dieses Programm ist eine wahre Bit-Frickel-Stube. >> Wenn du einfach willkürlich Bits wegwirfst, >> geht auch der letzte Rest an Zufall abhanden. > > Blödsinn, ich werfe nur Bits weg, die quasi Konstanten sind. > Du siehst das einfach diametral falsch herum. > Was soll ich mit Bits, die sich nur alle paar Stunden ändern? > >> Weshalb sollte das LSB zufälliger sein als >> das vorletzte? > > Weil sich das LSB am schnellsten ändert. > Noch nie einen mechanischen Zähler mit Radwalzen angeschaut? > Von rechts nach links kommen da die Überträge. > Das rechte Rad dreht sich am schnellsten. > >> Hast du dir mal angeschaut, wieviel Mühe >> im Linux-Kernel darauf verwendet wird, >> den kleinsten Rest an Entropie in den >> Pool hineinzumixen? (ChaCha20) >> Ich bezweifle, dass deine naive >> Implementation besser ist. > > Der NIST-Test bescheidet das aber so (besser als rdrand), mehrfach bisher. Gleichverteilung bedeutet nicht Unvorhersagbarkeit. Da muss man z. B. auch auf Seitenkanalattacken achten. Pi ist vielleicht gar nicht so zufällig: Es gibr gar nicht so weit hinten eine Folge 99999. Und man kann jede Nachkommastelle berechnen ohne Kenntnis der Vorgänger: -- Stefan