random_rdtsc und random_rdrand

Am 18.10.2026 um 19:13 schrieb Volker Bartheld:

Für einen Artikel in PoC||GTFO reicht es vermutlich nicht, die Editoren kippen vorher um...

Bernd

Könnte man das nicht per x'p/f'up in sci.crypt, de.comp.security.misc, de.sci.mathematik, sci.crypt.research, sci.crypt.random-numbers, alt.security.pgp, talk.politics.crypto diskutieren? Bevor das Usenet 2027 endgültig abgeschaltet wird, käme da noch etwas Schwung in die Bude.

Empfehle Chuck Schellong auch, das Projekt auf:

Volker

Könnte man das nicht per x'p/f'up in sci.crypt, de.comp.security.misc, de.sci.mathematik, sci.crypt.research, sci.crypt.random-numbers, alt.security.pgp, talk.politics.crypto diskutieren? Bevor das Usenet 2027 endgültig abgeschaltet wird, käme da noch etwas Schwung in die Bude.

Empfehle Chuck Schellong auch, das Projekt auf:

Volker

Danke! Das ist wirklich überzeugend und sogar für mich zu verstehen. OK, es setzt auf die optische Mustererkennung des menschlichen Gehirns auf, so ziemlich das leistungsfähigste, das wir haben, aber trotzdem.

Du hast vollkommen recht. Nachfolgend wird das glasklar deutlich gemacht:

Unter dem Link wird glasklar geschildert, wie ein OTP mit seiner _immer gleichen_ Verschlüsselung:

Es gab mehrmals das Resultat 43 64 96 an gleicher Position 0:

Es wird nun in dieser NG stoisch behauptet, ich würde meinen OTP0 mehrfach auf zu verschlüsselnde Dateien anwenden.

------------------------- ------------------------- | | | | | | | | | | | | | OTP0 | ---> | Flickengenerator | ---> Geheimnis | | | | | (Datenquelle) | | (Verschlüsselung) | | | | |

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

Nein, das ist falsch, weil vorstehend der OTP0 vom Flicken-Generator entkoppelt wird! Der Flicken-Generator verwürfelt alle _Positionen_ und verschlüsselt dann damit. Der Flicken-Generator verwendet bei seinen nächsten Verschlüsselungen jeweils gänzlich andere Repräsentationen! Jede seiner Verschlüsselungen ist prinzipiell zwingend einzigartig! Dies stellt zudem eine unbedingte Einmal-Verwendung dar.

Wegen dieser wiederholten Verwürfelung aller Positionen sind alle Möglichkeiten eines 'Knackens', die unter dem Link oben dargestellt sind, vollkommen entfernt!

Die Eigenschaften des Flicken-Generators sind durch seine gezeigten Arbeits-Tabellen bewiesen.

Ich hoffe, die gezeigte wirkliche Realität wird hier irgendwann einmal erfaßt.

Ich sach nur: Vier! *

Zu einfach? okay: 56? 66? 237?

Thomas Prufer

Und:

"Die indische Zertifizierungsstelle eMudhra hat acht ihrer Zwischenzertifikate widerrufen, nachdem bekannt wurde, dass sich deren private Schlüssel nahezu sofort berechnen lassen. Wer einen dieser Schlüssel besitzt, kann für jede beliebige Website ein Zertifikat ausstellen, das Browser und Betriebssysteme als vertrauenswürdig akzeptieren. Damit ließen sich Websites imitieren und verschlüsselte Verbindungen abfangen. "Ursache ist ein Fehler bei der Schlüsselerzeugung. Laut Mozilla sind die privaten Schlüssel der acht Zwischenzertifikate, die auf dem Verfahren P-384 basieren, sehr kleine ganze Zahlen statt zufällig gewählter 384-Bit-Werte. Sie bestehen faktisch nur aus Nullen, abgesehen vom letzten Byte. Der Sicherheitsforscher Flüpke veröffentlichte zur Demonstration einen der Schlüssel auf GitHub: Der private Schlüssel des Zertifikats „EM OV TLS CA – G3C” hat den Wert 4. Die übrigen Schlüssel lauten laut Berichten unter anderem 56, 66 und

Wie gemein, da wird sich das Programmkommittee totlachen.

Grüße Marc

Das ist doch sehr hypothetisch, was der Volker so über mich und den Kontext denkt. Das ist eine Welt, die ich fast hasse. Hat mit meinen Interessen kaum eine Berührung. Ich bin ein professioneller Entwickler für Elektronik und Programmierung.

falsch : Programmkommittee richtig: Programmkomitee

Mein aktuelles Interesse ist:

------------------------------------------------------------------------------- Mehrfache Nutzung eines One-Time-Pad (OTP) Copyright (c) 2026 - Helmut Schellong, Vlotho

noffs 8192 active 6140 size_otp 2000000000 size_infile 1072607232 gapM 244132 min 32 max 2193376 lenM 176321 min 32 max 1717776 gapM 244140 = 2000000000/8192 lenM 172659 = (2000000000/8192) / 1.414 # 0 offs: 1742350192 gap: 9808 len: 6400 r 0001 # 1 offs: 811493328 gap: 638624 len: 349128 r 0101 # 2 offs: 1483411776 gap: 36432 len: 22448 v 0000 # 3 offs: 648978992 gap: 224528 len: 145464 v 0100 # 4 offs: 1503789440 gap: 732896 len: 488088 r 0001 # 5 offs: 164514304 gap: 308816 len: 291112 r 0101 # 6 offs: 542922496 gap: 322256 len: 299144 r 0101 # 7 offs: 1479033152 gap: 110160 len: 64648 r 0101 # 8 offs: 1465449328 gap: 191968 len: 123728 v 0100 # 9 offs: 671877760 gap: 410976 len: 293776 v 0100

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

Die Analyse-Werte sehen gut aus. Ich hatte gerade an der Anpassungsfähigkeit des Kommandos gearbeitet.

Mit der Kontrolldatei kann --> Tabellentext generiert werden, teilweise eine Rekonstruktion. Mit dem Tabellentext kann eine Kontrolldatei generiert werden.

Mit der Verschlüsselung beginne ich nun zum Schluß.

Da diesbezüglich offenbar Verwirrung herrscht: xkcd/221 ist _kein_ Industriestandard.

"8 Bit reichen locker!"

Man liest sich, Alex.

Helmut Schellong wrote on 21.10.2026 01:15:

Wenn ich das mal etwas weiterführe:

Die einzige bekannte Methode, ein OTP unsicher zu machen, ist diejenige unter dem Link oben. (Vorausgesetzt ist stets eine gute kryptographische Qualität des OTP.) Es werden Dateien ab Adresse 0 mit einem OTP ab Adresse 'konstant' mehrfach linear verschlüsselt.

Mit der Ausgabe des Flicken-Generators funktioniert dies wegen verwürfelter Positionen nicht! Wie hoch ist die Wahrscheinlichkeit, daß an der OTP-Offset-Adresse 824277904 eine bestimmte Byte-Folge aus dem OTP später noch einmal auftritt? Nun, es könnte nach vielleicht 82 Milliarden Verschlüsselungen so etwas auftreten. Das wäre dann erst die zweite Verwendung! In diesem Fall wäre allerdings ein zeitlicher Bezug zwischen den Verwendungen nicht vorhanden.

Es schält sich heraus, daß hier ein Gleichnis vorliegt, mit der Aussage, daß ein Key mit

. struct { pid_t pid; time_t tim; ullong tsc1, tsc2; byte ctim[24], stack[256]; } seed;

Vorstehend die 6 Entropie-Quellen des Flicken-Generators.

Es ist wahrhaft abenteuerlich, zu behaupten, mein oben dargestelltes Konzept würde den OTP0 in schädlicher Weise mehrfach verwenden!

----------------------------------------------------------------------------------- noffs 128 active 41 size_otp 3837607 size_infile 1107376 gapM 29941 min 80 max 168912 lenM 21582 min 48 max 133848 gapM 29981 = 3837607/128 lenM 21202 = (3837607/128) / 1.414 Thu Oct 22 12:35:51 2026 # 0 offs: 3692000 gap: 48208 len: 31296 v 0000 # 1 offs: 2507312 gap: 27984 len: 14928 r 0001 # 2 offs: 984464 gap: 121440 len: 117808 r 0101 # 3 offs: 3203408 gap: 2400 len: 1984 r 0001 # 4 offs: 2217200 gap: 45376 len: 31752 v 0000 # 5 offs: 392304 gap: 13344 len: 10656 v 0100 # 6 offs: 2535296 gap: 20480 len: 12296 v 0000 # 7 offs: 3205808 gap: 40368 len: 25352 v 0000 # 8 offs: 2345568 gap: 28432 len: 15136 v 0000 # 9 offs: 1868768 gap: 2144 len: 2048 v 0000 # 10 offs: 967152 gap: 4736 len: 3432 r 0101

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

Vorstehend eine Arbeitstabelle mit 128 Offsets statt 8192 Offsets. Die Entropie ctim[24] oben ist ein Text-Zeitstempel, wie vorstehend enthalten.

Bei der _Verschlüsselung_ wird vorstehend der Offset neben Index 0 selbstverständlich stets zuerst verwendet - und der ist nicht (nie) 0! ('nie' ist eine praktische Aussage.)

Alle Offsets werden praktisch wahrscheinlich niemals wiederkehren, zumindest nicht bei vielen Offsets, wie 8192 und mehr.