Echter Zufall mit iTSC-counter

Leo Baumann wrote on 26.09.2026 04:20:

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.

Shannon: Das Verschlüsselungsverfahren ist perfekt sicher, genau dann, wenn die Wahrscheinlichkeitsverteilung auf dem Schlüsselraum die Gleichverteilung ist und wenn für jeden Klartext und jedes Chiffrat genau ein Schlüssel existiert.

Arno Welzel wrote on 26.09.2026 13:12:

Doch, selbstverständlich kann ein Computer das - gerade ein Computer mit seiner Hardware. Das habe ich mehrfach dargelegt. Mein Kommando erzeugt im Wesentlichen die echte Zufälligkeit. Ich habe aber keine Lust mehr, dies anhand des Quellcodes analytisch darzulegen. Es wird beharrlich nicht wahrgenommen oder nicht verstanden.

https ist bei einer Nur-Lese-Webseite ohne Nutzen.

Leo Baumann wrote on 26.09.2026 04:54:

Du bist ein Witzbold, der unverständliche Aussagen abliefert.

Am 26.09.2026 um 16:22 schrieb Helmut Schellong:

Für ein Kryptografieprojekt sind PRNGs mit RDTSc-Seed tabu!

:)

Leo Baumann wrote on 26.09.2026 16:29:

Ich verwende allerdings keinen rdtsc-seed, auch keinen PRNG, sondern etwas gänzlich Anderes!

Am 26.09.2026 um 16:35 schrieb Helmut Schellong:

haha - einen rdtsc-seed!

:)

Reinster Sündenfall, also. Um John von Neumann zu zitieren: Anyone who considers arithmetical methods of producing random numbers is, of course, in a state of sin. -- John von Neumann

SCNR, Alex.

Hopfen & Malz verloren, oder?

"echte Zufälligkeit" -- und bist sicher, das es zB im Silizium keine Backdoor gibt? Sowas gibt's. [1] nur so als erster Treffer, als Beispiel.

Oder die hunderte Geisterfahren blinken nicht zum Spaß mit der Lichthupe.

In einer von der National Security Agency entwickelter und veröffentlichter kryptographisch sicherer Zufallszahlengenerator (PRNG) fand sich eine "kleptographische Backdoor". [2] Hättest du die erkannt?

Thomas Prufer

[2] Dual_EC_DRBG

Ich hoffe, dass solche Grundsatzaussagen nicht davon ablenken, dass die Erzeugung von höchsten (kryptografischen) Ansprüchen genügenden Zufallszahlen auf modernen Betriebssystemen ein technisch gelöstes Problem ist.

Das Betriebssystem

- sammelt Zufälligkeit (Entropie) aus den verfügbaren Quellen, wie die zeitliche Streuung von Ein-/Ausgaben und Netzverkehr oder auch dafür gebauten Quellen wie RDSEED, die letztlich auf stochastische physikalische Prozesse zurückgreifen,

- rührt (hash) das alles zusammen,

- benutzt es periodisch als Saat für einen Pseudozufallszahlengenerator, wie eine Stromchiffre, der damit einen Zufallszahlenstrom erzeugt.

Als Benutzer holt man sich Zufallszahlen über eine entsprechende API vom Betriebssystem bzw. aus der Laufzeitumgebung.

Nein, auf den Gruppenkasper gehe ich nicht ein.

Ich habe es berichtet, wurde aber nicht wahrgenommen oder nicht verstanden.

Schon mal was von Betriebssystem oder 'Geräten' im Computer gehört?

Ja, beispielsweise.

Das ist irrelevant für mein Kommando. Es sind verschiedene Welten.

Am 26.09.2026 um 17:06 schrieb Alexander Schreiber:

Der gute Herr Neumann; ist ein sehr kluger Mensch gewesen im Gegensatz zu manch anderen hier...

Unser Geisterfahrer will angeblich eine Datensicherung verschlüsselt auf einem fremden Rechner abspeichern. Manche nennen das Cloud. Das allerbeste ist, dass der Schlüssel bei dieser Methode genau so groß ist wie die Daten. Wo sichert man dann den Schlüssel? Unterm Teppich oder in einer anderen Cloud?

Was will man da machen: Keine Ahnung von Datensicherungskonzepten, keine Ahnung von Zufallszahlen, keine Ahnung von seitenkanalunempfindlicher Kryptographie.

Manch einer würde sagen: Die dumme Seite sehr stark in ihm ist.

Gruß Andreas

Das ist stets die beste Lösung.

Die Grundsatzaussagen oben treffen auf mich auch gar nicht zu.

. 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.

Helmut Schellong wrote on 27.09.2026 02:07:

Das Zauberwort in der Beschreibung oben ist 'Steuerungszwecke'.

. sleep( Dbitmask & 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.

Zur binären Ausgabe verwertet werden allerdings wesentlich weniger Bits des TSC: . output( Wbitmask & 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.

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.

Das ist im Moment eine Idee von mir, ja.

oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo aaaaaaaaaaaaaaaaaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbbbb

Bei solchen Offsets kann jedenfalls nichts passieren. a und b haben ja ihren exklusiven o-Anteil.

oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo aaaaaaaaaaaaaaaaaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbbbb rrrrrrrrrrrrrrrrrrrrrrrrrrrrr r = a ^ o ssssssssssssssssssss s = b ^ o

Der vorstehende Fall müßte untersucht werden. r und s sind die per o verschlüsselten a und b. Der Angreifer verfügt nur über r und s. Weiter untersuchen werde ich das per Skript. Nur bei Schnittmenge dürfte ein Angriff Erfolg haben.

Helmut Schellong wrote on 27.09.2026 20:24:

Es war mir klar, daß ich mit Offsets und Schnittmenge gegen 'one time' verstoße. Die mögliche Folge davon war mir bis dahin in ihrem Ausmaß noch nicht klar. Ich kann auch alle paar Monate neue Pads generieren. Die Untersuchung per Skript werde ich allerdings dennoch durchführen.

Helmut Schellong wrote on 27.09.2026 20:24:

Ich habe das nun per Skript etwas untersucht.

let "r==(va^vo) && s==(vb^vo)" && { echo $n: $vo $va $vb; let ++n; }

Der Ausdruck hat zur Folge, daß von knapp 17 Mio Schleifendurchläufen genau 256 zu einer Ausgabe führen. Alle möglichen OTP-Werte (o) 0..255 passen zu irgendeiner Kombination von a und b. Der Informationsgehalt ist folglich Null. Wahrscheinlich werde ich da nicht weiter untersuchen. Aber ich halte erfolgreiche Angriffe für möglich, weil zwei durch ein und denselben Pad verschlüsselte Dateien durch eine Schnittmenge prinzipiell eine Verknüpfung bilden.

Helmut Schellong, 2026-09-26 16:19:

Nein, gerade *wegen* der Hardware des Computers ist es nicht zufällig. Auch dann nicht, wenn sich irgendwelche Zähler zwischen Funktionsaufrufen um Millionen ändern. Die Geschwindigkeit der Zähler ist nämlich keinesfalls zufällig, sondern ein *Timestamp*, dessen Wert das genaue Gegenteil von "Zufall" ist, egal ob die CPU im "Giga-Hertz-Bereich" läuft.

Im Kontext von Meltdown und Spectre wurden die Werte des TSC auch verwendet, um die exakten Ausführungszeitpunkte für Operationen festzulegen, die den Angriff ermöglichten.

Da

Am 03.10.2026 um 22:59 schrieb Arno Welzel:

Was "Chuck" Helmut Schellong sich ausgedacht hat , hat er irgendwo gepostet:

Zitat Schellong: "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. "