Echter Zufall mit iTSC-counter

Deine vorstehende herabsetzende Bemerkung zeigt auf, daß Du von meiner Art von Analysen nichts kennst.

Solche Ausgaben sind entscheidend für eine Analyse durch mich. Ich erkenne daran die Charakteristik und Qualität von solchen Zahlenreihen. Wenn ich 30 solche Ausgaben gesehen habe, ist die erste Stufe meiner Analyse durch. Bei einer Hex-Darstellung mache ich Flächenbelegungs-Beurteilungen - die zweite Stufe. Alles innerhalb von Minuten.

Am 19.09.2026 um 08:31 schrieb Stefan Wiens:

BTW, der Server-Prozessor vom Online-Assembler 'myCompiler' beherrscht den Assemblerbefehl rdseed nicht...

section .text global _start

_start: ; Schritt 1: Prüfen, ob RDSEED unterstützt wird mov eax, 7 ; Funktion 7 (Erweiterte Features) xor ecx, ecx ; Subfunktion 0 cpuid ; CPU-Informationen abfragen

; Das Ergebnis für RDSEED steht im Register EBX an Bit-Position 18 shr ebx, 18 ; Verschiebe Bit 18 an die erste Stelle (Bit 0) and ebx, 1 ; Maskiere alle anderen Bits aus (nur noch 0 oder 1)

cmp ebx, 1 ; Unterstützt die CPU RDSEED? je .rdseed_ok ; Wenn ja, springe zu Erfolg

; --- FALLBACK / FEHLER --- ; Wenn RDSEED NICHT unterstützt wird, beendet sich das Programm mit Code 100 mov rdi, 100 jmp .exit

.rdseed_ok: ; --- ERFOLG --- ; Wenn RDSEED unterstützt wird, beendet sich das Programm mit Code 0 xor rdi, rdi

.exit: mov rax, 60 ; Systemaufruf-Nummer für sys_exit syscall ; Programm beenden

... wird mit exit code 100 beendet.

Grüße

Am 19.09.2026 um 08:31 schrieb Stefan Wiens:

Zufallszahl mit Read-Seed, RDSEED - Assemblerprogramm, der Vollständigkeit halber ...

:)

Leo Baumann wrote on 21.09.2026 18:43:

Die Instruktion rdtsc speichert ihren 64-bit-Wert in die beiden 32-bit-Register edx und eax. Das ist generell portabler! Deshalb verzichtete ich bisher auf rdrand und andere.

Am 21.09.2026 um 20:26 schrieb Helmut Schellong:

Was aus rdtsc abgeloeitet wird ist kein echter Zufall!

Pseudozufall!

Nicht geeignet für Kryptographie, leicht manipulierbar und vorhersehbar!

Also Mist!

Helmut Schellong wrote on 20.09.2026 23:03:

Den NIST-Test hat die Methode 'rdtsc' weit überwiegend nicht bestanden. Das ist für mich allerdings irrelevant, weil meine Sichtung und Analyse der Ausgabedaten (Dez-Zahlen + Hex-Zahlen) deutlich positiv ist.

Mir gefällt der etwas 'wilde' Charakter dieser echten Zufallszahlen. Ich werde eine binäre Datei mit 10 GB Größe anfertigen und damit meine Dateien verschlüsseln. Dazu muß ich nur eine weitere Position in mein bestehendes Verschlüsselungs-Skript aufnehmen.

Diesen langen Datenstrom werde ich mit zufälligem Offset verwenden. Ich werde sicherstellen, daß kein Offset mehr als einmal benutzt wird. Der lange Datenstrom ist inhaltlich absolut einzigartig, und bleibt dies auch. Der Datenstrom wird sicher verwahrt.

Bitte nicht hier posten ...

Nur mit dem kleinen Detail das rdtsc den internen Time Stamp Counter ausliest, mit der Konsequenz das ein so geseedeter PRNG zwar für Würfelspielchen ausreicht, man damit aber keine kryptographisch sicheren Zufallszahlen generieren kann.

Man liest sich, Alex.

Leo Baumann wrote on 21.09.2026 20:33:

Nein.

Und nochmals Nein.

Keineswegs.

Der _unabhängige_ TSC-Counter zählt innerhalb von 0,322 ns um 1 hoch, bei mir. Das bedeutet, daß er von der Wirkung der gesamten Hardware (bis ins feinste Detail) des Computers hochgezählt wird. Bereits eine einzige der zeitlich kürzesten Instruktionen läßt ihn hochzählen! Fast jede Aktion in meinem TSC-Programm läßt ihn millionenfach hochzählen!

Alles ist dabei unvorhersehbar, weil von der Hardware bestimmt.

Am 21.09.2026 um 21:49 schrieb Helmut Schellong:

Chuck Schellong, Du hast einen Standesdünkel - Du hast kein Diplom - gehe erstmal neu studieren bevor Du uns mit Deinem Schwachsinn beschäftigst!

Leo Baumann wrote on 21.09.2026 21:56:

Die Realität ist von meinem abgebrochenen Studium nicht abhängig! Die physikalischen Vorgänge laufen trotz Deiner falschen Behauptungen faktisch ab. Nichts dagegen machen Du kannst.

Am 21.09.2026 um 22:07 schrieb Helmut Schellong:

Ein iTSC (Invariant Time Stamp Counter) eines Prozessors liefert keine echten, physikalisch unvorhersehbaren Zufallszahlen, sondern dient als hochpräziser Takt- und Zyklenzähler.Technische EinordnungFunktionsweise: Der Befehl RDTSC (Read Time Stamp Counter) liest die Anzahl der vergangenen CPU-Taktzyklen seit dem Systemstart aus. Ein Invariant TSC läuft unabhängig von Turbo-Modi oder Energiespar-Taktungen mit einer konstanten, nominalen Frequenz weiter.Kein echter Zufall: Der Zähler erhöht sich deterministisch mit jeder Schwingung. Er ist daher per se nicht zufällig oder kryptografisch sicher.Verwendung als Seed: Man kann den iTSC-Wert jedoch als Startwert (Seed) für einen Pseudozufallszahlengenerator (PRNG) verwenden, um bei jedem Programmstart eine andere Zahlenfolge zu erzeugen. Für echten Zufall oder sicherheitsrelevante Anwendungen (Kryptografie) ist er ungeeignet, da Timing-Muster und Startzeitpunkte oft erraten oder rekonstruiert werden können. Moderne CPUs bieten stattdessen dedizierte Hardware-Befehle wie RDRAND oder RDSEED, die auf echtem thermischen Rauschen basieren.

Präzise Uhren alleine eignen sich nicht als Zufallsquellen.

Beweis durch Aufstampfen mit dem Fuss, oder wie?

Tja ..

Und Du verbreitest mal wieder Unfug. Der TSC zählt clock cycles seit CPU reset. Je nach CPU-Variante wird entweder mit konstanter Frequenz gezählt oder es wird mit der tatsächlichen aktuellen Core-Frequenz gezählt, die durch power management variiert wird. Ja, das heisst das je nach CPU-Variante verschiedene cores in derselben CPU andere Zählerwerte haben.

Und auf hinreichend modernen CPUs läuft der TSC eh als iTSC (invariant Time Stamp Counter), d.h. mit es wird mit konstanter Frequenz gezählt, unabhängig von aktueller Prozessorfrequenz oder power management state. Der iTSC ist damit im wesentlichen eine CPU-interne Präzisionsuhr und wird auch so verwendet, sowohl vom Kernel als auch von Applikations- software.

Nein. Eine typische - und meist durchaus erwünschte - Eigenschaft einer Uhr (und das ist der iTSC) ist die präzise Vorhersagbarkeit.

Man liest sich, Alex.

Leo Baumann wrote on 22.09.2026 01:35:

Du hast eine falsche Blickweise zum Thema.

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.

Genau so ist es mit dem TSC-Counter. Nur, daß dieser noch viel schneller und damit besser ist.

Rechts sind die Differenzen zum jeweiligen Vorgänger-Wert dargestellt. *** Warum sind die Differenzen so stark unterschiedlich, und derartig hoch? *** Die Werte gehen von 56189 bis 38897528. Zusätzlich sind die Differenzwerte gut durchgemischt, ohne erkennbare Tendenz. Kein Differenzwert kommt mehr als einmal vor, auch nicht bei viel mehr Zeilen.

time writes to the standard error stream, (in seconds): . the total time elapsed, the time used to execute the utility process and . the time consumed by system overhead. . 0.68 real 0.00 user 0.22 sys . 0.67 real 0.00 user 0.21 sys

Der Aufruf 'tsc= rdtsc()' steht doch im Quelltext ganz oben in der Schleife. Vor und nach dem Aufruf werden doch viele Instruktionen ausgeführt, die jeweils einen Zeitbedarf haben. Wobei eine Instruktion einen Bedarf von z.B. 9..38 Takten haben kann - praktisch unvorhersehbar. Dabei schwankt die Taktfrequenz des Prozessors von z.B. 800..4700 MHz - nicht voraus berechenbar. Der TSC hingegen wird mit einer Festfrequenz von 3100 MHz (bei mir) getaktet. Auch das mehrstufige Cache-System hat unvorhersehbare Zeitvorteile. Jegliche Benutzung von Geräten (Bildschirm, Festplatten, etc.) hat einen jeweiligen Zeitbedarf. Hinzu kommen die vielen nicht voraus kalkulierbaren Zeitbedarfe des Betriebssystems.

Während all dieser Zeitbedarfe kann der TSC nicht gelesen werden, denn der Standort ist eben _nicht_ der Aufruf 'tsc= rdtsc()', sondern man steht halt woanders im Verarbeitungsablauf. Und während all dieser Zeitbedarfe zählt der TSC superschnell hoch! Beim nächstmöglichen Lesen des TSC gibt dieser eben einen unvorhersehbaren Wert zurück! Der Start des Kommandos 'randtsc' ist ebenso zu einem zufälligen Zeitpunkt, aus Sicht des TSC.

Alle _gelesenen_ Werte des TSC sind folglich überhaupt nicht deterministisch, sondern echter Zufall. Es ist gar nicht möglich, _jeden_ Zählerstand des TSC nacheinander per Instruktion 'rdtsc' zu lesen!

Du hast eines (absichtlich) nicht bemerkt: Daß ich aus der Sicht eines laufenden Programms schrieb, welches den TSC wiederholt liest. Jeder Zeitbedarf in diesem Programm läßt quasi den TSC weiter hochzählen. Insofern ist Dein Beitrag in diesem Posting alberner Quatsch.

Zum iTSC las ich, daß dieser ausschließlich mit der Nennfrequenz der CPU getaktet ist.

Ich schrieb aus der Sicht eines laufenden Programms, welches den TSC wiederholt liest. Jeder Zeitbedarf in diesem Programm läßt quasi den TSC weiter hochzählen.

Ich habe den TSC schon vor nicht wenigen Jahren dafür benutzt, um die Laufzeit von zeitlich langen Instruktionen zu messen - also als Uhr. Die Instruktionen habe ich jeweils vielfach hintereinander wiederholt.

Ich kenne (folglich) fast alle Aspekte in diesem Zusammenhang seit 'ewigen' Zeiten. Das kann von mir erwartet werden, als jemand, der seit 1985 als Entwicklungsingenieur für Elektronik und Programmierung arbeitete.

Das kann so gesagt werden. Deshalb kann ich in meinem Kommando 'randtsc' die Anzahl Bits einstellen, die ich von LSB her jedem TSC-Wert entnehme.

Weiterhin habe ich ein Delay programmiert, ebenso mit einstellbarer Anzahl Bits. Dieses Delay wird dem TSC-Wert selbst entnommen, ist also eine Rückkopplung. Bei Bits=0 ist diese Zusatz-Verzögerung ebenso 0.

Es ist für mich ganz sicher, daß ich einen sogenannten One-Time-Pad mit _diesen_ Zahlenfolgen konstruieren kann. Meine visuelle Analyse reicht eigentlich schon für diese Aussage.

Hi Helmut,

An Selbstbewußtsein fehlt es Dir nicht, ich würde es Überheblichkeit nennen.

Genau: Prellvorgänge und in erster Linie die manuelle Betätigung, die wenigstens eine Unabhängigkeit vom Zähler vorzuweisen hat. und nicht zwei recht deterministische Taktgeneratoren miteinander vergleicht.

Es geht deutlich besser

Nicht wirklich, wie Du doch mit dem NIST-Test selbst festgestellt hattest.

Dein erster Blick hat mit Wissenschaft nicht viel zu tun.

Sie sind zwar sehr komplex aber nicht zufällig, weil nach einem festen Programmablauf ermittelt. Warum nicht einfach den Zufallsgenerator nehmen, der da ist und wirklich Zufall liefert?

Marte

Rein technisch kann man ein One-Time-Pad auch mit einer Serie von lauter Nullen konstruieren. Ist zwar für ernstzunehmende Verschlüsselung nicht sinnvoll, aber man kann das so machen (Ok, sinnvoller Einsatz für sowas wäre ein kurzer Test, um grobe Fehler in der Implementation zu finden).

Erfahrene Kryptographen benutzen detaillierte stochastische Analysen um die Qualität von Zufallszahlenserien zu ermitteln während unser Helmut solcherlei Krücken nicht braucht und das mit einem kurzen Blick einschätzen kann. Was sind wir immens beeindruckt.

SCNR, Alex.