random_rdtsc und random_rdrand

Sep 29, 2026 Last reply: 2 days ago 190 Replies

Leo Baumann wrote on 02.10.2026 06:29:

Doch, weil die Werte vom TSC zufällig sind und weil die Wirkungen der unterlegten externen HW+SW permanent wirken.

. sleep( [ D_bitmask & tsc ] + D_Computer );

Vorstehende symbolische Darstellung hatte ich ebenfalls gepostet.

Das erste Lesen des TSC liefert auf jeden Fall einen echt zufälligen Zählerstand. Dieser Zählerstand wird benutzt, um eine Verzögerung mit zufälliger Länge zu bilden. Während dieser Verzögerung inkrementiert der TSC um einen zufälligen Betrag.

Diese Programmierung ist halt ein sehr wirksamer Kunstgriff meinerseits.

Der jeweils nächste gelesene Wert des TSC ist N_I_E vorhersagbar! (1) Das ist faktisch prinzipiell so, wie bei RDRAND.

(1) Die 13 Dezimalstellen von links her (MSB) des TSC sind längere Zeit konstant. . Werte aus diesem Bereich werden allerdings ohnehin nie verwendet.

Am 02.10.2026 um 16:02 schrieb Helmut Schellong:

Zählerstände vom TSC sind nicht zufällig.-

Auf Anfrage an die KI ist Deine Zahl sowohl vorhersagbar und keine echte Zufallszahl. Deine Zahl ist kryptographisch nicht sicher.

Willst Du behaupten die AI lügt oder halluziniert?

Was ist zufällig an der Zeit seit dem Reset?

Aber du hast auch belegt, dass du mit echten Zufallszahlen nichts sinnvolles anfangen kannst, wenn du sie mehrfach verwendest.

Erstmal wäre zu prüfen, _ob_ das Ergebnis schwankt, dann kann man ggfs. fragen _warum_.

Ich habe vor einigen Jahren mal geschaut, was für einen initialen TSC-Wert ein x86-BIOS-Bootloader ausliest, und die unteren Bits haben tatsächlich wild gewechselt. Warum auch immer. Ein bisschen Entropie scheint da schon drinzustecken.

Hintergrund war, dass der OpenBSD-Bootloader schon Zufälligkeit einsammelt, um sie dem Kernel mit auf den Weg zu geben, falls verfügbar:

- ein Block Zufallszahlen, der geschrieben wurde, als das System zum letzten Mal lief¹;

- von der Firmware, UEFI bietet sowas;

- auf x86 von RDSEED, RDRAND und auch RDTSC.

¹) Beim Booten über TFTP fragt er das auch vom TFTP-Server ab und der OpenBSD tftpd(8) liefert auf jede solche Abfrage einen frischen Block Zufallszahlen.

Es kommt auf das konkrete Lesen des Zählerstandes des TSC an! Das ist das Zufällige!

Aus altem Posting: In den 1980er Jahren wurden Lotto-Generatoren angeboten. Einer hatte einen 10-MHz-Counter, der von 1..49 in der Runde zählte. Aktiviert wurde er durch Tippen auf einen mechanischen Taster mit Prellverhalten. Der Counter brauchte 4,9 us für 49 Zählschritte. Das sind 204 Durchläufe von 1..49 innerhalb einer Millisekunde. Das waren einwandfreie echte Zufallszahlen.

Der TSC inkrementiert etwa 3000-mal innerhalb einer Mikrosekunde. Niemand kann innerhalb von Piko-Sekunden eine mechanische Taste drücken. Beispielsweise die Enter-Taste, um das Kommando aufzurufen. In der Zeit vor Beginn des Taste-Drückens hat der TSC zudem viel mehr gezählt, als während des Taste-Drückens.

Die erste gelesene Zahl vom TSC ist doch zufällig - zufälliger geht es nicht so einfach - RDRAND ist graduell zufälliger.

Die Prellzeit einer Taste liegt bei vielleicht 20 ms. Mein TSC zählt währenddessen 62111801 Schritte hoch.

Du hast nun den OTP-Gedanken hervorgeholt. Es gibt für echte Zufallszahlen mehrere Anwendungsfälle.

Beispielsweise, wenn man 16 kleine Zahlen für ein kleines Array braucht, um ein Einschleifen, eine Zusammenführung optimal zu gestalten.

Beispielsweise können die beiden großen Arrays (2x256x32bit) im Algorithmus Dragon echte Zufallszahlen enthalten. Die Verwendungsart isoliert sie nach außen.

Für große OTP-Dateien hatte ich eine Verwendung von Offsets überlegt. Bei meiner Erfahrung kann ich das im Detail so gestalten, daß es kaum möglich ist, erfolgreich dagegen zu agieren: Und zwar Offsets im _gesamten_ Raum des OTP verteilt. Der Byte-Strom wird im Kreis herum, und vorwärts oder rückwärts abgetastet. Es gibt hier noch weitere einfache Möglichkeiten, um Verwirrung zu stiften!

Leo Baumann wrote on 02.10.2026 16:11:

Wann hört Ihr mal auf, den TSC völlig isoliert zu betrachten?

Ich bin der KI haushoch überlegen, weil diese nicht kreativ ist. Die KI befindet sich hier in einer ihr eigenen typischen Hilflosigkeit und plappert auswendig Gelerntes daher.

Am 02.10.2026 um 22:00 schrieb Helmut Schellong:

hahahaha

Der volle 64-Bit-Wertebereich nach dem Reset wird wohl kaum je erreicht, denn irgendwann steht ein Reboot an.

Wieviel Entropie in den niedrigen Bits steckt, ist ebenso unklar.

Und evtl. kann der TSC von einem anderen Core belauscht werden, das reduziert zwar nicht die Zufälligkeit, aber die kryptographische Sicherheit.

Leo Baumann wrote on 02.10.2026 22:02:

Paß auf, daß Du nicht wegen zu großer Gläubigkeit gegenüber der KI zum Degenerierten wirst.

Leo Baumann wrote on 02.10.2026 22:20:

Das Programm manipuliert aber nicht den TSC. Der TSC ist vollkommen unabhängig, bis auf seine Betriebsspannung und Enable = true.

Am 02.10.2026 um 23:11 schrieb Helmut Schellong:

Das Programm manipuliert den Zeitpunkt an dem der TSC gelesen wird.

Hi Leo,

Das machen die ständig und das ohne rot zu werden. Hast Du schon einmal erlebt, dass eine AI gesagt hat, dass sie etwas nicht wisse?

Marte

Leo Baumann wrote on 02.10.2026 23:51:

Ja, aber es nutzt dazu blind die maskierten Zufallswerte vom TSC.

Nein, die AI Systeme lügen natürlich nicht. Sie produzieren Bullshit. Und ja, es gibt da einen wichtigen Unterschied. Nach Harry G. Frankfurt ("On Bullshit"): - Der Lügner hat ein Interesse daran, das die Lüge geglaubt wird. - Dem Bullshitter ist es vollkommen egal, ob man ihm glaubt oder nicht.

Im Umgang mit den Aussagen von AI-Systemen gilt: "Niemals vertrauen, immer kontrollieren."

Man liest sich, Alex.

So wie das aussieht, wird im Linux-Kernel dem Ergebnis von rdtsc keinerlei Entropie gutgeschrieben, es gibt wohl Ausnahmefälle nach dem Booten, wo evtl. ein Bit gutgeschrieben wird.

Das ist ein riesiger Unterschied zu der naiven Implementierung, die hier vorgestellt wurde.

Am 03.10.2026 um 14:49 schrieb Stefan Wiens:

Der erste gelesene TSC-Wert nach dem Einschalten des Computers (zufälliger Tastendruck im Raum-Zeit-Kontinuum) ist eine echte Zufallszahl.

Alle gelesenen TSC-Werte danach nicht.

Dabei hätte sie nur sagen müssen, dass es keiner weiß, denn sonst hätte sie es beim Training gelesen.

Grüße, H.

Das ist irrelevant, weil hier _erneut_ eine völlig isolierte Betrachtung des TSC vorgenommen wird. Das ist schlicht dumm.

Diese angeblich naive Implementation (randtsc) hat sich den hochgelobten Instruktionen 'rdrand' und 'rdseed' als _überlegen_ herausgestellt!

Die NIST-Tests weisen 21-, 13- und 2-, 20-mal das Vorkommen des Worts FAILURE aus. Der Reihe nach für 'rdrand', 'rdseed', 'randtsc langsam', 'randtsc schnell'. Der Reihe nach:

formatting link
Der NIST-Test 800-22 mit 188 Tests ist relevant und beweiskräftig.

Leo Baumann wrote on 03.10.2026 15:21:

Das stimmt, reicht aber nicht aus. Jedes Starten durch eine Taste, eines den TSC lesenden Programms, liefert eine echte Zufallszahl.

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.

Viele kreative und kompetente natürliche Personen wissen es. Allerdings weiß die KI nicht, daß diese es wissen.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required