Einzelnen Beitrag anzeigen

Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.640 Beiträge
 
#25

AW: Noise XOR Signal = Noise?

  Alt 14. Jul 2014, 23:12
Was du schreibst ist also ein ganz klarer Widerspruch zur Sicherheit des One-Time-Pad.
Ist es nicht. Du legst mir ja auch wieder Sachen in den Mund die ich nie gesagt habe.

Das One-Time-Pad wird nicht als permanenter Zufallsstrom verwendet, in dem ab und zu eine Nachricht eingeflochten wird.
Das One-Time-Pad ist eine doppelt gespeicherte (endliche) folge von Zufall, aus dem pro Nachricht immer genau so viel als Schlüssel verwendet wird, um die Nachricht vollständig zu verschlüsseln. Andersrum: Habe ich eine 100 Byte lange Nachricht, nehme ich die nächsten 100 Byte aus dem OTP als Schlüssel. Da die gesamte(!) Nachricht aus Noise XOR Signal besteht, ist eine statistische Analyse wo denn jetzt Signal anfängt oder aufhört weder Sinnvoll (es steckt eh immer Signal drin), und vor allem wäre es auch aussichtslos, da nie genug Daten für eine Analyse vorlägen.


Aber mal ganz praktisch:

Noise XOR Noise = 0. Alle Bits sind null. Eine Glatte Nulllinie.

Das heisst: lege ich perfekten Zufall über perfekten Zufall, und analysiere diesen Zufall statistisch in seiner Gesamtheit, so werde ich absolut keinerlei Auffälligkeiten finden.


Noise XOR Noise ist also 0, und nicht Signal.
Daher kann Noise XOR Signal nicht Noise sein, denn Noise XOR Noise ist wieder Null und das Signal wäre flöten. Daher ist Noise XOR Signal maximal Noise2. Nur dann können wir aus Noise2 XOR Noise wieder das Signal erhalten.


Dort, wo das Signal anliegt, unterscheiden sich Noise und Noise2. An den Stellen, an denen das Signal nicht anliegt, ist Noise2 wieder mit Noise1 identisch. An den Stellen, an denen Noise2 nun von Noise unterschiedlich ist, wird ein XOR mit Noise nicht mehr zu glatten Nullen führen, sondern zu anderen Werten - nämlich dem Signal.


Perfekter Zufall beinhaltet auch Muster, und diese wiederholen sich zufällig. Die Wiederholung jedes einzelnen Patterns in einem Zufallsstrom ist wieder rein zufällig und daher auch normalverteilt.

Was heisst das nun aber, wenn wir uns Noise2 an den Stellen angucken, an denen das Signal anlag?

Richtig: Noise2 unterscheidet sich von Noise. Das heisst, es findet sich dort eine andere Bitfolge - ein anderes Muster - das bei perfektem Zufall eben nicht genau dort wäre. Dieses Muster wird sich in im normalen Zufallsstrom auch - mehrmals - wiederfinden, aber an anderer Stelle. Das Muster, das in Noise an dieser Stelle war, ist entsprechend auch nicht mehr an dieser Stelle vorhanden.

Schaue ich mir nun Noise2 in einer ausreichend großen Menge an, so wird mir auffallen, das zwei bestimmte Muster auffallen. Eines kommt statistisch gesehen zu wenig vor (nämlich das, was in Noise1 an dieser Stelle war), und ein anderes Muster tritt zu oft auf (nämlich das, das durch das Signal erzeugt wurde). Wenn man sich nun die zufällig auch normalverteilten Abstände zwischen den Mustern anschaut, dann wird man, wieder bei ausreichender Datenmenge, auch erkennen können, dass der Abstand zwischen zwei bestimmten Mustern deutlich größer ist als normal und interessanterweise genau an dieser Stelle auch das andere auffällige Muster, mit einem sehr wahrscheinlich auffallend engen Abstand zu anderen seines gleichen vorkommt.

Voilá, ich habe mit einer leicht erhöhten Wahrscheinlichkeit feststellen können, das vermutlich an dieser Stelle der echte Zufall modifiziert wurde.



Oder als Herausforderung:
Zitat:
Phonix, konstruiere ein Signal, dass auch nach xor mit einem zufälligen Bitstrom noch ein Bit Information überträgt.
Siehe oben. Da braucht man nichts zu konstruieren.
Nehme eine beliebige Zahl und XORe sie mit Zufall. XORe den gleichen Zufall erneut, und die Original-Information ist weiterhin vorhanden. Wenn die Information nicht im Ergebnisstrom wäre, dann wäre das ja keine umkehrbare Verschlüsselung, sondern z.B. ein Hash-Algorithmus, bei dem die Original-Information verloren geht und nur ein (reproduzierbares) Abbild der Information übrig bleibt.
Sebastian Gingter
Phoenix - 不死鳥, Microsoft MVP, Rettungshundeführer
Über mich: Sebastian Gingter @ Thinktecture Mein Blog: https://gingter.org
  Mit Zitat antworten Zitat