On 2026-09-30, Helmut Schellong snipped-for-privacy@schellong.biz wrote: [lange Liste mit Crypto-Literatur...]
"Granddad was superstitious about books. He thought that if you had enough of them around, education leaked out, like radioactivity."
-- (Terry Pratchett, Johnny and the Dead)
cu Michael
Am 30.09.2026 um 11:03 schrieb Helmut Schellong:
tsc ist vorhersagbar und eine prima Abszisse für die Berechenbarkeit Deiner angeblich programmierten Entropie.
Das ist eine reale Sichtweise.
Blos dass Deine Software nicht intelligent ist, sondern gegen einige o.g. Anforderungen widerspricht.
Solche Sprüche mag ich meistens nicht. Sie spiegeln die Meinung einer Person; ich gehe nicht konform mit dem heutigen Spruch.
Es ist völlig korrekt und gerade bei Deinem "Niveau" könntest Du aus jedem seiner Artikel etwas lernen, und wenn es nur eine realistischere Selbsteinschätzung ist.
Du blamierst Dich hier jeden Tag bis aus Blut und merkst es nichtmal.
Grüße Marc
Deine programmierte Entropie gibt es nicht, die ist exakt 0 Joule/Kelvin :)
Leo Baumann wrote on 30.09.2026 16:58:
TSC ist nur isoliert und theoretisch betrachtet vorhersagbar.
[...] Pi ist eine transzendente und nicht-periodische Zahl, und ist einem Divisionsrest ähnlich. Man braucht aber rund eine Million Bits pro Bitstream für optimales Arbeiten des NIST-Tests.Gegen welche denn? Deine Aussage oben: "... Deiner angeblich programmierten Entropie." ist eine Falschbehauptung.
Ich kritisierte bereits: Mehrere andere Poster stellen bloße Behauptungen auf, wo ich Nachweise beifüge. Den Test nist1.txt postete ich bereits mehrfach. Dennoch wird dieser knallharte Beweis komplett übergangen, weil er wohl 'unangenehm' ist.
Am 30.09.2026 um 18:12 schrieb Helmut Schellong:
Wie bereits mehrfach geschrieben kann der NIST-Test weder Unvorhersagbarkeit noch Entropie bestätigen!
• Was der NIST-Test nicht kann: Er kann nicht erkennen, ob eine Zahlenfolge vorhersagbar ist. Wenn Sie beispielsweise die Nachkommastellen der Zahl Pi in Binärcode umwandeln und testen, wird diese Sequenz die NIST-Tests problemlos bestehen, obwohl sie absolut deterministisch und unelastisch vorhersagbar ist. • Kryptografische Sicherheit: Ein Generator ist erst dann sicher, wenn er sowohl den statistischen NIST-Test (SP 800-22) besteht als auch eine nachweisbar unvorhersagbare Entropiequelle (SP 800-90B) nutzt.NIST SP 800-90B: Diese Norm regelt die Anforderungen an die eigentliche Entropiequelle (z. B. Hardware-Rauschen), um echte physikalische Unvorhersagbarkeit mathematisch nachzuweisen.
:) - Tschüß "Chuck" Helmut, es reicht uns jetzt!
Leo Baumann wrote on 30.09.2026 17:33:
Eine platte Behauptung - wiederholt. Und Beweis (s.u.) gelöscht.
Am 30.09.2026 um 18:12 schrieb Helmut Schellong:
Weis der Henker was Du da für einen komischen Text aus welchem Programm auch immer andauernd als Beweis anführst - vollkommener Blödsinn.-
Ein NIST-Test kann keine Unvorhersagbarkeit und Entropie bestätigen!
Leo Baumann wrote on 30.09.2026 18:25:
Der NIST-Test bestätigt durch einen APPROXIMATE ENTROPY TEST. Wahrscheinlich angenähert, weil Hardware nicht beteiligt ist.
Bei meinem TSC-Kommando wirkt ebenfalls die Hardware des Computers in unvorhersehbarer Weise. Eigentlich ein mehrfach aufgerufenes altes Thema - siehe auch Posting von Christian Weisgerber. Ich könnte das sogar beweisen.
Die Instruktion 'rdrand' ist _nicht_ gemäß NIST SP 800-90B, 'rdseed' allerdings doch. In meinem Kommando sind beide verfügbar.
Auch jeder Aufruf des TSC-Kommandos bewirkt echte Zufälligkeit - durch den Aufruf selbst. All diese Nachweise verschwinden regelmäßig immer wieder in der Versenkung.
Leo Baumann wrote on 30.09.2026 18:45:
Das ist eine massive Schmähung von Deiner Seite. Blasphemie kann auch gesagt werden.
nist1.txt wurde von der NIST-Test-Suite (SP 800-22) hergestellt.
Am 30.09.2026 um 19:25 schrieb Helmut Schellong:
Der NIST-Test kann die Unvorhersehbarkeit und Entropie nicht bestätigen.-
Was die da mit "approximate entropy" meinen ist unklar.
Leo Baumann wrote on 30.09.2026 20:10:
Helmut Schellong wrote on 30.09.2026 20:49:
Der Test prüft die Zufälligkeit/Gleichverteilung des Bitstroms.
Am 30.09.2026 um 20:49 schrieb Helmut Schellong:
Also hat das mit der physikalisch gemeinten Entropie nichts zu tun.
Leo Baumann wrote on 30.09.2026 20:55:
Ja, es gibt die physikalische und die informationstheoretische Entropie. In der Test-Suite geht es um die Entropie von Shannon mit Gleichverteilung.
Am 30.09.2026 um 23:32 schrieb Helmut Schellong:
Fassen wir zusammen:
TSC ist vorhersagbar und hat keine Entropie- Dein Programm müsste die Zahlen also unvorhersagbar machen und irgendwie eine Entropie erzeugen- Durch Programmierung ist das nicht erreichbar- Egal was Du programmierst, es ist berechenbar-
Der NIST-Test bestätigt die Unvorhersagbarkeit und phys. Entropie *nicht*- Der NIST-Test bestätigt die statistische Zufälligkeit von Bitketten, die von Zufallszahlengeneratoren erzeugt wurden.- Der Zufallszahlengenerator muss aber Unvorhersagbar sein und eine Entropiequelle haben-
Deiner hat das aber nicht.
Leo Baumann wrote on 01.10.2026 00:50:
Doch, ich habe es erreicht.
Nein. Ich habe schon vor langer Zeit zufällige Verzögerungen benutzt.
Doch, alles dies hat er sehr wohl.
Lies das Posting von Christian Weisgerber, und/oder:
=============================================================================================================== [27.09.2026, 12:47]
. Mein Kommando 'randtsc' liest den TSC-Counter und nutzt dessen Werte . für Steuerungszwecke und zur Ausgabe zum Bildschirm und in eine Datei.
Vorstehend die komplette Beschreibung der Kernfunktion meines Kommandos.
.
Die Ausgabe des Kommandos ist nicht deterministisch, keine PRNG-Ausgabe und nicht wiederholbar.
Das Zauberwort in der Beschreibung oben ist 'Steuerungszwecke'.
. sleep( D_bitmask & tsc );
Ich habe eine Verzögerungszeit programmiert, wie vorstehend symbolisch dargestellt. 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. Dieser Betrag kann einen maximalen Zahlenwert von etwa 100.000.000 haben. Das ist die maximale Differenz zwischen zwei nacheinander gelesenen Zählerständen.
Diesem unterliegt die Wirkung der Gesamtheit der Hardware und Software des Computers: . sleep( [ D_bitmask & tsc ] + D_Computer ); Hier ist ein weiterer wirksamer Anteil von echtem Zufall vorhanden.
Zur binären Ausgabe verwertet werden allerdings wesentlich weniger Bits des TSC: . output( W_bitmask & tsc ); Der hier vorliegende Wertbereich wird folglich sehr oft komplett durchlaufen. Es wird berücksichtigt, daß sich das niederwertigste Bit am häufigsten ändert! Das ist eine vorliegende Unsymmetrie.
Nachfolgend eine beweiskräftige Ausgabenserie des Kommandos 'randtsc':
. randtsc 300 Differenz D_bitmask . 00000275187.129.340245 0000027518712.9340245 10 . 00000275187.156.451316 0000000000002.7111071 10 . 00000275187.159.386832 0000000000000.2935516 10 . 00000275187.160.711210 0000000000000.1324378 10 . ... . 00000275189.769.798642 0000000000002.8283528 1 . 00000275189.774.950741 0000000000000.5152099 1 . 00000275189.780.630313 0000000000000.5679572 1 . 00000275189.786.154246 0000000000000.5523933 1 . 00000275189.788.205427 0000000000000.2051181 0 . 00000275189.793.859874 0000000000000.5654447 0 . 00000275189.801.675332 0000000000000.7815458 0 . 00000275189.803.471061 0000000000000.1795729 0
Vorstehend wurde eine Ausgabe zum Bildschirm vorgenommen. Der Regler des Kommandos verringert fortlaufend die interne Verzögerung, weil die Verzögerung von außen (durch das Terminal) seine Vorgaben übersteigt. Trotz Erreichung des Wertes 0 ändert sich die starke, zufällige Modulation nicht.
. randtsc 300 0 > dez.txt Differenz . 00000278625.325.111329 0000000000000.0009248 0 . 00000278625.325.120324 0000000000000.0008995 0 . 00000278625.325.129312 0000000000000.0008988 0 . 00000278625.325.137763 0000000000000.0008451 0 . 00000278625.325.147368 0000000000000.0009605 0 . 00000278625.325.339997 0000000000000.0192629 0 . 00000278625.325.351150 0000000000000.0011153 0 . 00000278625.325.360940 0000000000000.0009790 0
Vorstehend wurde nicht mehr zum Bildschirm ausgegeben, und die interne Verzögerung wurde abgeschaltet. Dennoch beträgt die Verzögerung mindestens über 8000 Inkrements des TSC. Es kommt auch der hohe Wert 192629 vor - großer Sprung durch Externes. Das ist natürlich auch echter Zufall. Der Wertehub ist hier viel zu gering für eine hochqualitative Ausgabe.
. randtsc 300 > dez.txt Differenz . 00000276928.790.366209 0000000000000.0184004 10 . 00000276928.790.377807 0000000000000.0011598 10 . 00000276928.790.569007 0000000000000.0191200 10 . 00000276928.790.606470 0000000000000.0037463 10 . 00000276928.790.971766 0000000000000.0365296 11 . 00000276928.791.756231 0000000000000.0784465 11 . 00000276928.792.575959 0000000000000.0819728 11 . 00000276928.793.703713 0000000000000.1127754 11
Vorstehend eine gewöhnliche Ausgabe. Die Bitbreite von D_bitmask wird hier nicht reduziert, sondern vom Regler erhöht. Der Wertehub liegt hier im Bereich von Millionen, so daß hochqualitative Ausgaben (W_bitmask) möglich sind.
Ein Betriebssystem war schon in den 1980ern sehr komplex (z.B. SCO-Unix). Es gab z.B. 'Dirty Blocks'. Das sind Daten im RAM, die noch nicht auf eine Festplatte abgesichert wurden. Dies wurde unter SCO nach einer Verzögerung von 30 Sekunden begonnen zu tun. (Ich hatte diesen Zeitwert damals auf 9 s reduziert.) Dies wurde nicht stramm mit höchster Priorität getan, sondern wurde z.B. durch massive Zugriffe locker unterbrochen, oder durch Start von mehreren Prozessen, etc. Ein Scheduler ist eine der wichtigsten und komplexesten Funktionen.
Alle Funktionen des Betriebssystems zusammen erzeugen ein im Detail unvorhersehbares Konglomerat an Verzögerungen wie auch Bevorzugungen. Eine Mikrosekunde Verzögerung im betreffenden Prozeß verhindert bereits das Lesen von mehr als 3000 Inkrements des TSC - und erzeugt echten Zufall. ===============================================================================================================
Am 01.10.2026 um 18:35 schrieb Helmut Schellong: [...]
Alles Schrott was Du da gemacht hast!
Am 01.10.2026 um 18:35 schrieb Helmut Schellong:
Die Anweisung erzeugt keine Entropie!
Have something to add? Share your thoughts — no account required.
Ask the community — no account required