One-Time-Pad - wirklich nur eine einzige Verwendung eines OTP?

Oct 05, 2026 Last reply: 3 hours ago 3 Replies

First reply

Hergen Lehmann

Das ist eine sehr gefährliche Fehleinschätzung. Wiederverwendung des gleichen Schlüssels für unterschiedliche Kommunikation ist Ansatzpunkt Nummer1 für Angriffe. Schon wenige abgefangene verschlüsselte Nachrichten genügen, um zusammen mit Annahmen über den Klartext…

Read the full reply

Das Thema wurde geringfügig im Zusammenhang mit dem Stichwort 'Offset' angesprochen.



Ich meine, nach etwas mehr Nachdenken darüber, daß OTPs durchaus gefahrlos quasi mehrfach verwendet werden können.



Lösung:



Ich erzeuge durch einen kryptographischen RNG einige Hundert 64bit-Offsets. Die unterziehe ich einer Restwert-Division, so daß sie im OTP zugeordnet werden können. Danach wird ein geeignetes Alignment dieser Offsets hergestellt.



Anschließend werden nacheinander alle diese Offsets angesprungen, um Daten aus dem OTP zwecks Verschlüsselung zu gewinnen. Dabei werden die Daten auch ringförmig abgegriffen, und vorwärts oder rückwärts. (Es gibt noch weitere grundlegende Mittel zur Verschleierung.) Die abgreifende Länge wird aus dem jeweiligen Offset gewonnen.



Für jede Verschlüsselung wird folglich eine gänzlich andere Bytefolge abgegriffen, als es die lineare Abfolge des OTP ab Adresse 0 darstellt. Es handelt sich jedes Mal um einen riesigen, nicht vorhersehbaren Flickenteppich.



Alle diese Maßnahmen sind einfach und schnell. Die beteiligten Dateien befinden sich in einer RAM-Disk (/ram).



Am 05.10.26 um 13:40 schrieb Helmut Schellong:

Das ist eine sehr gefährliche Fehleinschätzung.

Wiederverwendung des gleichen Schlüssels für unterschiedliche Kommunikation ist Ansatzpunkt Nummer1 für Angriffe. Schon wenige abgefangene verschlüsselte Nachrichten genügen, um zusammen mit Annahmen über den Klartext (Buchstabenhäufigkeit, häufig verwendete Formulierungen, Dateiheader, etc.) eine große Zahl von Schlüsseln ausschließen und den Suchraum drastisch verkleinern zu können.

Womit du den Suchraum für eine BruteForce-Attacke von 2^<Schlüssellänge> auf die <Schlüssellänge> reduziert hast...

Am 05.10.2026 um 13:40 schrieb Helmut Schellong: ...

Nach all den Hinweisen war das der Tropfen zu viel im Faß, Glückwunsch zur bestandenen Prüfung!

Hergen Lehmann wrote on 05.10.2026 14:49:

Ein Schlüssel wird hier gar nicht ersichtlich. Der Klartext fehlt, und der beteiligte OTP fehlt, weil verschleiert. Es gibt hier nur verschlüsselte Dateien, die _nicht_ mit demselben OTP verschlüsselt wurden.

Ich glaube keinesfalls, daß extrem verschleiertes Lesen exponentiell unsicherer ist als vollkommen unverschleiertes lineares Lesen ab Adresse 0. Das macht die Sache hier unglaubwürdig.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required