random_rdtsc und random_rdrand

Jeder einzelner Deiner Kunden tut mir aufrichtig leid.

--

---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Du kennst keinen einzigen meiner 'Kunden'. Keine dieser Personen (eine 3-stellige Anzahl) hat sich je über mich beklagt. Ich mußte in Jahrzehnten wohl zweimal etwas nachbessern. Eher erhielt ich Lob, vom meinen direkten Vorgesetzten mehrfach und auch von einer Ebene direkt unter der des CEO.

Was Du da oben indirekt behauptest, ist komplett bescheuert und unwahr. Irgendwie scheinst Du krank im Kopf zu sein, so etwas ablassen zu müssen.

Dennoch tun sie mir leid.

Das spricht wohl dafür dass sich niemand Deine "Leistungen" näher angeschaut hat.

Das was Du hier ablieferst ist wirklich mit Abstand unter aller Kanone. Diese Kombination aus Unfähigkeit, Hybris und Beharrlichkeit ist mir in meiner bis 1984 zurückreichenden Laufbahn echt nur zwei, dreimal untergekommen,

Das ist ein großer Irrtum. Die Kunden haben im Laufe der Zeit hunderte Wünsche an mich gehabt. Keine Klagen über meine Arbeit! - Wie kommts? Bis auf wohl zwei Nachbesserungen. Da wurde trotz Funktion ein anderes Verhalten von Menüs von mir verlangt.

Du hörst nicht auf, unhaltbare Behauptungen über mich aufzustellen! Diese passen gar nicht zu den realen Beurteilungen über mich in Jahrzehnten. Ich meine damit gute bis sehr gute Zeugnisse und verbales Lob.

Meine Laufbahn begann 1968.

Und als Zeichen meiner übergroßen Unfähigkeit habe ich in den letzten 6 Tagen ein Programm 'Mehrfache Nutzung eines One-Time-Pad (OTP)' entwickelt:

.

In den zurückliegenden Wochen habe ich eine ganze Reihe neuer Programme entwickelt (6?), die alle auf Anhieb funktionierten und in meine normale Verwendung übergegangen sind. Ich bin ja sooo unfähig!

Am 15.10.2026 um 08:30 schrieb Marc Haber:

Da kann ich Dir nur zustimmen (wie wohl fast alle hier (bis auf Einen)). Bei mir ist das bis jetzt nur einmal vorgekommen + Diesem hier. Ich bin immer nur erstaunt, wie beharrlich manche Leute sein können.

Irgendwann wird wohl der jugendliche Leichtsinn durch Altersstarrsinn ersetzt ;-) Eine Einsicht kann man in dem Alter wohl nicht mehr erwarten.

Gruß Andreas

Noch deutlich schlimmer ist es, eine solche Persönlichkeit zum Kollegen zu haben. Ein Kollege, der sich für Gottes Geschenk an die Menschheit hält, ist wirklich extrem anstrengend. Und ich weiß wovon ich spreche :-/

Obiges eingegeben in die Suchmaschine meiner Wahl:

(tu's nicht)

und weitere sites mit "tu's nicht".

Aber klar, wenn mann's besser weiß wie ein Schneier, dann kann man das schon so machen, oder?

Was weiss dieser Schneier schon von Verschlüsselung, soll er doch erstmal bei unserem Meister Schellong in die Lehre gehen!

SCNR, Alex.

Ich sehe, daß mein Lösungskonzept, das ich hier vor wenigen Wochen mehr als einmal erklärte, und jetzt wieder per Arbeitstabelle erkläre, nachhaltig nicht begriffen wird.

.

Zweimal ein und dieselben Dateien verwendet:

------------------------------------------------------------------------------------- Sortierung 1: 4095 Sortierung 2: 4095

noffs 8192 active 6048 size_otp 2000000000 size_infile 1072607232 # 0 offs: 763669504 gap: 193440 len: 114985 'r' 10 # 1 offs: 1569404080 gap: 19296 len: 17678 'r' 00 # 2 offs: 1007410464 gap: 165664 len: 123928 'r' 10 # 3 offs: 66470640 gap: 474688 len: 278380 'v' 10 # 4 offs: 1282579504 gap: 79504 len: 49717 'v' 10 # 5 offs: 1059735808 gap: 25616 len: 14351 'v' 10 # 6 offs: 1612565024 gap: 121280 len: 62157 'r' 00 # 7 offs: 786581920 gap: 38816 len: 24381 'r' 10 # 8 offs: 257909472 gap: 73440 len: 68207 'v' 10 # 9 offs: 702688352 gap: 272352 len: 235090 'v' 10 # 10 offs: 804357360 gap: 23312 len: 17196 'r' 10 # 11 offs: 1192324512 gap: 237824 len: 135258 'v' 10

------------------------------------------------------------------------------------- Sortierung 1: 4093 Sortierung 2: 4092

noffs 8192 active 6091 size_otp 2000000000 size_infile 1072607232 # 0 offs: 1360589296 gap: 158224 len: 93504 'v' 10 # 1 offs: 1224584320 gap: 26896 len: 17035 'v' 10 # 2 offs: 822188112 gap: 185392 len: 102081 'r' 10 # 3 offs: 1505296112 gap: 100256 len: 64883 'r' 00 # 4 offs: 1442050592 gap: 414784 len: 245993 'v' 10 # 5 offs: 1351202352 gap: 308592 len: 210550 'r' 10 # 6 offs: 1152875008 gap: 262464 len: 258429 'v' 10 # 7 offs: 213878784 gap: 189376 len: 108746 'v' 10 # 8 offs: 564804544 gap: 171760 len: 86151 'v' 10 # 9 offs: 1944598624 gap: 316400 len: 183407 'r' 00 # 10 offs: 40161568 gap: 126416 len: 115682 'v' 10 # 11 offs: 735124960 gap: 36624 len: 24197 'r' 10

-------------------------------------------------------------------------------------

Trotz derselben Dateien wurden vollkommen unterschiedliche Arbeitstabellen generiert! Man beachte 'Sortierung, aktive' und nachfolgende Zeilen.

Die Parameter-Werte { offs, gap, len, v:r } sind durch kryptographische Zufallszahlen entstanden. Der Seed des Generators (2048 Bit) wird durch 5 verschiedene Entropie-Quellen von HW und OS erzeugt.

Ab dem 'offs' im 'otp' wird gelesen, 'gap' ist der Abstand zum nächsten 'offs'. Gelesen werden 'len' Bytes, mit denen 'infile' ab Adresse 0 bündig verschlüsselt wird. 'v:r' entscheidet, ob vorwärts oder rückwärts gelesen wird. Nach bzw. vor 'len' bleibt eine variabel große Lücke der Nichtverwendung bestehen.

Bei jeder Verschlüsselung wird ein vollkommen anderer OTP-Inhalt -> 'infile' generiert! Der jeweilige Inhalt ist ein riesiger Flickenteppich. Kein Flicken ist identifizierbar, weil das OTP eine Gleichverteilung aufweist. Das OTP muß hier mindestens 1,5-fach größer sein, als die zu verschlüsselnde Datei. Die 'offs' werden stets im gesamten Raum des OTP verteilt.

Es ist praktisch ausgeschlossen, daß eine bestimmte Sequenz des OPT _mehrfach_ mit gleichen Inhaltsteilen in jeweiligen 'infile' an _gleicher_ Position signifikant verknüpft wird. Ich sehe mein Konzept und Algorithmus daher als sicher an.

Dass One-Time-Pads nicht mehrfach zu nutzen sind ist "Kryptografie

Obendrein sind One-Time-Pads in der heutigen Kryptografie zu Recht ins Hintertreffen geraten, unter anderem weil man bei One-Time-Pads das Problem, den Klartext geheimhalten zu müssen verdoppelt, weil man nebenbei nun auch das One-Time-Pad, das genauso lang ist wie der zu verschlüsselnde Klartext, geheimhalten muss.

Das ist ein Verfahren fürs Lehrbuch, das undiskutierbare, theoretische Vorteile hat, dafür aber operationale Nachteile in es unpraktikabel machender Größe hat. Auch in der geheimdienstlichen Praxis wurden One-Time-Pads höchstens für die Verschlüsselung kürzester Nachrichten verewendet.

Dass Du der Meinung bist, das einzige Verfahren zur sicheren Mehrfachverwendung von One-Time-Pads erfunden zu haben, woran sich die weltbesten Kryptografen der letzen hundert Jahre die Zähne ausgebissen haben, zeigt doch nur wie sehr Du dich überschätzt.

Ich könnte die Wand hochgehen wenn ich solche Dinge von Dir lese.

In deiner Vorgehensweise sehe ich nichtmal den Ansatz einer seriösen Kryptoanalyse.

Grüße Marc

--

---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Am 15.10.2026 um 17:10 schrieb Helmut Schellong:

Ich nehme an, um die Datei zu entziffern, muss man dem Empfänger nun diese Tabelle geben? Die Tabelle ist also der Schlüssel?

Herzlichen Glückwunsch. Du hast (fast) eine Vingenere-Chiffre gebaut. Stammt aus dem 16. Jahrhundert. Du hast nur ein größeres Alphabet benutzt, statt Buchstaben aus dem Codewort eben Indizes in dein "OTP".

Für den Anwendungsfall "Daten scramblen, damit der Flashspeicher es beim Wear Leveling einfacher hat" ist das Verfahren sicher, aber viel zu kompliziert.

Für den Anwendungsfall "Krypto" taugt das nichts. Es wird zwar niemand knacken, aber das liegt daran, dass die damit verschlüsselten Daten zu wenig Wert und Umfang haben...

Stefan

Und das Brechen einer Vigenère-Chiffre (u.a. mittels Kasiski-Test) ist eine der klassischen Fingerübungen aus der "Einführung in die Kryptographie" Vorlesung. Damals vor vielen Jahren selbst gemacht in den Übungen dazu.

Man liest sich, Alex.

Wenn die Vorlesung etwas langsamer als üblich verläuft. ;-)

Eben, das ist halt das klassische Problem dabei.

Absolut sicher. Absolut unpraktikabel.

Typischerweise zur Übermittlung sehr kurzer Code-Nachrichten der Kategorie "Aktion #23, Zeit #42".

Hmm, Du meinst, die Schellong'sche Kryptographie-"Forschung" eignet sich als Kletterhilfe in den Bergen?

Man liest sich, Alex.

Jetzt rate mal, _warum_ ich diese Software entwickle? Genau wegen der nicht idealen Handhabung von OTPs.

Es ist für mich gar kein Problem, ein fettes OTP mit 10 GB gespeichert zu haben. Ich habe 2 x 18 TB Speicherplatz. Mindestens 35% davon frei.

Das, was mich stört, ist, _immer wieder_ für _jede_ neuere Backup-Datei eine neue OTP-Datei produzieren und diese verwahren zu müssen!

Dies entfällt komplett durch Verwendung meiner Software. Zudem kann ich diese eine große OTP ohne Schaden sogar verlieren oder teilen! Weil diese OTP nie direkt linear verwendet wird. Jeder Flickenteppich daraus existiert nur einmal.

Ich produziere prinzipiell beliebig viele einzigartige OTP-Flickenteppiche. Ich muß dazu nur eine kleine binäre Kontrolldatei aufheben, zwecks Entschlüsselung. Diese ist durch internen Hash (Keccak) gesichert.

Außerordentlich vorteilhaft finde ich mein Konzept hierzu!

Ja, weil Du Dich pauschal nach der uralten Lehre richtest: "Das haben wir schon immer so gemacht." "Und da ist einer, der es anders machen will. Das ist aber schlecht! Davon abraten muß man!"

Alles, ohne irgendwelche konkrete Einwände zu meiner Software. Ich habe in einem späteren Posting relativ ausführlich meine Software beschrieben. Und warum ich sie für sicher halte.

Das wäre auch fehl am Platz! Meine Software ist kein kryptographischer Code, sondern ein Flickenteppich-Generator. Eine extreme Verschleierung.

Ich verwende darin den Spritz-Algorithmus, der nicht von mir stammt.

Stefan Reuther wrote on 15.10.2026 18:24:

Du denkst Dir einfach etwas aus, das eben nicht stimmt!

Die Liste oben ist nur ein lesbarer Ausdruck, ein Service. Zum Entschlüsseln brauche ich eine binäre Version dieser Tabelle. Natürlich auch das OTP, denn oben sind Offsets in das OTP zu sehen.

Was ist daran kompliziert? Man ruft das Kommando auf, und - Patsch - ist alles fertig. Die Tabelle oben ist in Millisekunden fertig...

Letzteres stimmt. Unabhängig davon funktioniert die Software gut, die nicht kryptographisch ist.

Woher weißt Du das?: "Für den Anwendungsfall "Krypto" taugt das nichts." Die Software erfüllt ihren Zweck gut.

Weil Du zu viel Zeit hast. Nimm Dir eine handelsübliche Crypto-Library, wähle einen halbwegs anständigen Schlüssel und Dein Problem ist gelöst, und zwar besser als Du es selbst je können wirst.

Und wie schützt Du dieses OTP vor Zugriff? Den musst Du genau so schützen wie die schützenswerten Daten. Und backuppen!

Das ist aber bei OTP zwingend erforderlich, sonst hieße es MTP.

Und dabei entfällt auch komplett die Sicherheit der Daten.

Damit will ich mich nicht befassen, weil ich ahne, daß eine solche Library meine Vorstellungen nicht erfüllen wird. Erst einmal muß diese Software kostenlos sein, weil meine Software dies ist. Desweiteren müßte diese Software ein OTP verwenden, daß eine Qualität hat, wie die Zufallszahlen von meinem Kommando 'randtsc'. Usw.

An meine Daten kommt niemand heran, das ist sicher. Seit etwa 1985 ist niemand an meine Daten heran gekommen, oder hat es nicht versucht. Die Frage ist, wer will unbedingt an meine Daten kommen? Ein internationales Spezialistenteam würde das schaffen.

Backup - was soll diese Bemerkung? Ich habe doch etwa 20 GB bereits auf Backup im Internet gespeichert. Das ist doch bekannt. Ich könnte auch 100 GB dort speichern.

Diese Sicherheit entfällt überhaupt nicht! Und _warum_ sollte die Sicherheit entfallen? Die Tabellen, die ich öffentlich machte, enthalten zu 100% den jeweiligen Handlungsplan für eine konkrete Verschlüsselung - da fehlt nichts. Folglich könnte jeder, der hierzu Kompetenz hat, Unsicherheiten aufzeigen.

Solange so etwas nicht unternommen wird, werde ich platte Behauptungen nicht ernst nehmen. Dein Satz: "Und dabei entfällt auch komplett die Sicherheit der Daten." ist ein Null-Argument.

Mein Flickenteppich-Generator arbeitet so, als ob man z.B. 65536 beschriftete Zettel in ein Gefäß gibt, mit Preßluft vermischt und alle Zettel blind einzeln entnimmt und diese Reihenfolge notiert. Alle, die diese Reihenfolge nicht notiert haben, sind folglich hilflos. Was ist an einem solchen Konzept unsicher?