Entwickler-Ecke :: Thema anzeigen - XOR-Verschlüsselung, warum eigentlich nicht?

Delete - Di 27.11.07 22:03
Titel: XOR-Verschlüsselung, warum eigentlich nicht?

Als ich mit TurboPascal angefangen habe, wurde uns die XOR-Verschlüsselung beigebracht. Aber es hieß immer wieder, sie wäre nicht sicher. Aber wieso? Wenn ich eine Byte-Folge immer nur mit ein und dem selben Byte verknüpfe, dann ist mir klar, das man nur 256 Versuche braucht, um den Originalwert zu erhalten.

Aber wenn ich nun eine Byte-Folge als Schlüssel verwende, wie soll da jemand die Originalwerte errechnen?

Beispiel:

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:

type
  TAByte = Array of Byte;

function xorCode
         ( const pValue, pKey: TAByte )
         : TAByte;
var
  I1, I2 : Integer;
begin
  Result := pValue;
  I1     := 0;
  for I2 := 0 to High( Result ) do
  begin
    Result[ I2 ] := Result[ I2 ] xor pKey[ I1 ];
    if I1 + 1 <= High( pKey ) then
      Inc( I1 )
    else
      I1 := 0;
  end;
end;

Wenn die Gegenseite weiß, um was für Daten es sich handelt, dann ist es sicher einfach, die Daten dem bekannten Muster entsprechend zu entschlüsseln. Aber was, wenn ich einen längeren Schlüssel verwende und das Muster der Daten nicht bekannt ist?

Ich habe sicher einige Denkfehler nicht bemerkt. Verschlüsselung ist auch nicht das, womit ich mich täglich beschäftige. Mich würden Eure Erklärungen und Gegenbeispiele sehr freuen.

Moderiert von Narses: Code- durch Delphi-Tags ersetzt
Moderiert von Narses: Topic aus Off Topic verschoben am Di 27.11.2007 um 21:16

Delete - Di 27.11.07 23:28

ub60 hat folgendes geschrieben:

Aber zu Deinem Vorschlag. Im Endeffekt hast Du gerade die Vigenère-Chiffre neu erfunden, nur eben für Computer.
Das knacken ist für einen Text mittlerer Länge und für ein nicht all zu langes Passwort "relativ" einfach.

Mir geht es ja um Daten aller Varianten, nicht nur Text. Un der Schlüssel sollte ganz klar länger sein. 1 Byte ist Unsinn. Wie schon gesagt, max. 256 Versuche reichen um die Daten zu entschlüsseln.

Es geht nur darum, dass sehr oft gesagt wurde, die "Vigenère-Chiffre" wäre einfach zu knacken. Aber ich will das nicht wirklich glauben. Ich habe sie sehr oft benutzt und habe auch ein Tool geschrieben, welches Daten verschlüsselt. Und um das Muster der Daten zu verschleiern habe ich einen verschlüsselten Header voransetzt und die Datei-Erweiterung verändert. Den Schlüssel hat nur der Empfänger. Ich habe es so weit übertrieben, lol, dass ich Bitmaps, als Schlüssel verwendet hatte. Man konnte auch angeben, ob der Schlüsel als Schleife, wie oben im Delphi-Schnipsel, verwendet wurde, oder als PingPong-Schlüssel. D. h. wenn ich das letzte Byte des Schüssels verwendet habe, wird er rückwärts verwendet, dann wieder von vorn. Wenn ich den Header weglasse, verbrauche ich auch keinen Mehr-Speicherplatz.

Naja, bei einem beispielsweise 100 Byte großen Schlüssel, der aus Zeichen 31 <= X <= 255 besteht, wie hoch ist die Wahrscheinlichkeit, dass dann die Daten entschlüsselt werden?

Mich interessiert eben, wie sicher diese Verschlüsselung ist. Gibt es hier vielleicht einen Experten, der sagt, gib mal rüber, ich knacke Dir das?

//Edit: Um zu Delphifan zu ergänzen: Man könnte auch einen Schlüssel nehemen und einen reproduzierbaren Algorhythmus schreiben, der angibt, welches Byte aus dem Schlüssel als nächstes verwendet werden soll. So das die Gegenseite mit dem reproduzierten Algorhythmus die Daten entschlüsselt.

delfiphan - Di 27.11.07 23:42

@Neurologic Scientist: Man könnte das ja, aber das bietet nicht die gleiche Sicherheit. Wenn du z.B. einen Pseudo-Random-Generator mit einem Seed verwendest statt richtige Zufallszahlen bietet das nicht die selbe Sicherheit.

(PS: Um die vorherige Angabe bzgl. Quantenkryptographie zu präzisieren: Es ist in der Praxis so, dass ein Lauschangriff nur mit einiger gewissen Wahrscheinlichkeit detektiert werden kann. Diese Wahrscheinlichkeit kann man allerdings beliebig klein machen. Dies ändert aber natürlich nichts daran, dass die One-Time-Pad-Verschlüsselung beweisbar unknackbar ist. Es gibt halt genau so viele mögliche Schlüssel wie Anzahl Möglichkeiten, den Text zu dekodieren)

Delete - Di 27.11.07 23:56

Such mal in der http://www.delphipraxis.net nach Beiträgen von Hagen (Benutzername: negah). (Du solltest aber schon was von höherer Mathematik und Kryptologie verstehen, um seinen Ausführungen folgen zu können.*) Von ihm ist das DEC (Delphi Encryption Compendium. Und er ist der Verschlüsselungsexperte schlecht in in der Delphi-Welt.

*) Deswegen ist auch nur davon abzuraten als Anfänger auf diesem Gebiet versuchen zu wollen einen eigenen, sicheren Algorithmus entwerfen zu wollen.

Delete - Di 27.11.07 23:57

delfiphan hat folgendes geschrieben:

Wenn du z.B. einen Pseudo-Random-Generator mit einem Seed verwendest statt richtige Zufallszahlen bietet das nicht die selbe Sicherheit.

Jau, stimmt. Aber wenn ich 2 GB verschlüssele, dann bräuchte ich einen ebenso langen Schlüssel. Das bringt dann nicht wirklich etwas.

delfiphan hat folgendes geschrieben:

(PS: Um die vorherige Angabe bzgl. Quantenkryptographie zu präzisieren: Es ist in der Praxis so, dass ein Lauschangriff nur mit einiger gewissen Wahrscheinlichkeit detektiert werden kann.

Meinst Du "detektiert = festgestellt" oder "mit einer niedrigen Trefferquote Erfolg"?

delfiphan hat folgendes geschrieben:

Diese Wahrscheinlichkeit kann man allerdings beliebig klein machen. Dies ändert aber natürlich nichts daran, dass die One-Time-Pad-Verschlüsselung beweisbar unknackbar ist.

"Unknackbar", war das jetzt vertippt oder ernst?

Mal sehen ob ich es verstanden habe: Entscheidend ist, dass der Alghorhythmus gut durchdacht ist (Mischen des Schlüssels wie oben beschrieben, o. a.). Einen authentisch zufälligen Schlüssel zu produzieren wäre durch den entsprechenden Algorhythmus nicht zwingend notwendig, lang genug sollte der Schlüssel sein.

@ user profile icon

Luckie Da schau ich mal. Danke. Mal sehen, was meine Mathematik noch so hergibt. Öfter mal was Neues hat noch nie geschadet.

//Edit: user profile icon

Luckie Es ist mehr eine theoretische Frage, die mich seit Jahren beschäftigt. Im Zweifelsfall kann ich ja ein Paket erstellen und es dem Experten schicken. lol Nein, im Ernst. Probieren geht über Studieren!

delfiphan - Mi 28.11.07 00:12

Neurologic Scientist hat folgendes geschrieben:

Meinst Du "detektiert = festgestellt" oder "mit einer niedrigen Trefferquote Erfolg"?

Quantenkryptographie: Ein Lauschangriff kann nicht mit 100%iger Sicherheit festgestellt werden, sondern muss anhand einer Fehlerrate und eines Toleranzwertes festgestellt werden. Man kann typischerweise davon ausgehen, dass bei einem Lauschangriff im Mittel 25% der Bits fehlerhaft sind. Aber eben nur im Mittel - und wieviel jetzt in der Praxis wirklich falsch sind, gehorcht einer Zufallsverteilung. Natürlich ist die Wahrscheinlichkeit verschwindend klein, dass alle Bits keinen Fehler aufweisen, wenn im Mittel 25% der Bits falsch sein sollten. Aber nicht 0.

Neurologic Scientist hat folgendes geschrieben:

"Unknackbar", war das jetzt vertippt oder ernst?

One-Time-Pad ist beweisbar unknackbar, da es ebensoviele mögliche Schlüssel gibt, wie dekodierbare Nachrichten: Wenn du alle Schlüssel durchprobierst, hast du gleichzeitig alle möglichen Nachrichten durchprobiert. Welche davon die richtige ist, kannst du nicht wissen, da eben alle Möglichkeiten vorhanden sind: Mit einem Schlüssel kriegst du die Bibel raus, mit einem anderen den Koran und mit wieder einem anderen Schlüssel Hänsel und Gretel. Alle Möglichkeiten sind gleich Wahrscheinlich.

Delete - Mi 28.11.07 00:26

delphiphan hat folgendes geschrieben:

Mit einem Schlüssel kriegst du die Bibel raus, mit einem anderen den Koran und mit wieder einem anderen Schlüssel Hänsel und Gretel. Alle Möglichkeiten sind gleich Wahrscheinlich.

Erinnert mich an meinen Standpunkt zur Programmierung: Gib mir die Daten eines eingescannten Fotos von einem Haufen Hundescheiße, und mit dem richtigen Algorhythmus programmiere ich Dir aus genau diesen Werten ein Einfamilienhaus mit Garten.

OK. Danke. Jetzt weiß ich wenigstens, dass es Sinn hat, weiter mit XOR zu verschlüsseln.

Sinspin - Mi 28.11.07 00:35

ich verwende in meinem Verschlüsselungsprogramm auch nichts wesentlich anderes als XOR (eine Modulo-Addition) aber der Datenstrom der rauskommt ist Gleichverteilt.
Relevant ist wirklich nur der Schlüssel bei dieser Art von Verschlüsselung. Dieser MUS so lang sein wie die zu verschlüsselnden Daten und sollte NICHT von irgend einer Datei genommen werden. Weil diese wieder Muster enthalten kann mit denen sich das Knacken vereinfachen könnte.
Deshalb verwende ich den Zufallsgenerator ISAAC um den eigentlichen Schlüssel herzustellen. Intialisiert wird dieser mit dem Passwort das der Anwender zum verschlüsseln eingibt.
Von ISSAC behauptet der Entwickler das die erzeugten Zahlenreihen mindestenz 2^40 Byte lang sind. Was eigentlich ausreichen sollte um von der Seite her sicher zu sein.
Was natürlich klar ist, wenn es jemand geschafft hat, ein Stück zu entschlüsseln, bekommt er auch den Schlüssel für das Stück in die Hand und kann damit die weiteren Werte produzieren die nötig sind um den Rest zu entschlüsseln. Es ist ja schließlich nur eine Zahlenreihe und eine Formel.

ub60 - Mi 28.11.07 00:59

Neurologic Scientist hat folgendes geschrieben:

Es geht nur darum, dass sehr oft gesagt wurde, die "Vigenère-Chiffre" wäre einfach zu knacken.

Sie IST einfach zu knacken!

Neurologic Scientist hat folgendes geschrieben:

Aber ich will das nicht wirklich glauben.

Glaube es mal.
Zwei Stichworte: Kasiski-Test, Koinzidenzindex

Neurologic Scientist hat folgendes geschrieben:

Naja, bei einem beispielsweise 100 Byte großen Schlüssel, der aus Zeichen 31 <= X <= 255 besteht, wie hoch ist die Wahrscheinlichkeit, dass dann die Daten entschlüsselt werden?

Also, wenn es sich nur um deutschen Text handelt, und der Text einige KB groß ist, sehe ich darin kein Problem.

Neurologic Scientist hat folgendes geschrieben:

Gibt es hier vielleicht einen Experten, der sagt, gib mal rüber, ich knacke Dir das?

Nicht dass ich zu viel Zeit hätte, ..., aber es ist, mit kryptologischen Maßstäben gesehen, wirklich einfach. Soll nicht heißen, dass man da nicht ein paar Stunden dran sitzen muss.

ub60

Delete - Mi 28.11.07 00:59

sinspin
Wow. Der Schlüssel benötigt dann einen Mindestspeicherplatz von 1.099.511.627.776 Byte = 1 TB. Wo soll ein solcher Schlüssel für die Verarbeitung ausgelagert werden? Selbst wenn das latzte Byte immer wieder überschrieben wird, muss dieser Schlüssel für die entschlüsselung gepseichert werden. Wenn Du also 1 GB Daten verschlüsselst, z. B. eine .VOB einer DVD, hast Du die doppelte Menge an Daten. Wow. OK, es geht auch um die optimalen Laborbedingungen.

Ich denke, dass ein Schlüssel von 1.048.576 Byte = 1 MB Länge für alle Datenmengen ausreicht. Wenn man den noch ausreichend mischt, also per algorhythmus nicht linear verwendet, dann wird der Schlüssel ich nenne es mal "virtuell" länger.

ub60 hat folgendes geschrieben:

Also, wenn es sich nur um deutschen Text handelt, und der Text einige KB groß ist, sehe ich darin kein Problem.

Mir geht es um alle Arten von computergespeicherten Daten. Der Lauscher weiß nicht, was da aus seinem Ende der Leitung strömt. Bei einem Klartext wird ja sinnvollerweise oft mit einem Wörterbuch gearbeitet. Also sollte man die Hinweise entfernen.

ub60 hat folgendes geschrieben:

Nicht dass ich zu viel Zeit hätte, ..., aber es ist, mit kryptologischen Maßstäben gesehen, wirklich einfach. Soll nicht heißen, dass man da nicht ein paar Stunden dran sitzen muss.

Also wenn das jetzt ein Angebot war, mache ich Dir gern ein kleines Daten-Paket fertig.

//OK. Ich lass es für heute. 5 mal am Post rumeditieren ist nicht sinnvoll.

JayEff - Mi 28.11.07 10:47

Neurologic Scientist hat folgendes geschrieben:

Sinspin's Methode ist eine andere. User gibt Passwort ein. Aus Passwort wird Randomseed errechnet. Dieses wird an einen Zufallszahlengenerator übergeben, der den Schlüssel liefert. Für gleiche Randomseeds wird dieser Generator immer die selbe Sequenz an "Zufall" liefern. Folglich muss nur der Zufallsalgorithmus und das vom User eingegebene Passwort bekannt sein, um zu Entschlüsseln. Nicht etwa der komplette vom Generator generierte Schlüssel.

Neurologic Scientist hat folgendes geschrieben:

Ich denke, dass ein Schlüssel von 1.048.576 Byte = 1 MB Länge für alle Datenmengen ausreicht. Wenn man den noch ausreichend mischt, also per algorhythmus nicht linear verwendet, dann wird der Schlüssel ich nenne es mal "virtuell" länger.

Codiere damit eine 200MB große Textdatei und es ist SEHR einfach. Codiere ein 1GB AVI-Video und es ist schaffbar. (Zumal ich allein durch den Header der Videodatei die ersten X Byte des Schlüssels per Known-Plaintext Angriff bekomme.
Zu dem Thema empfehl ich dir mal, das Suche bei Google

CRYPTOOL anzuschauen. Das bietet dir kryptoanalytische Tools sowie einen Algorithmus, der einen Vigenere-Chiffre innerhalb von Sekunden knackt, solange der Text einigermaßen groß ist. Ich schätze, das 100fache des Schlüssels reicht schon für ein sicheres Ergebnis, dann reicht nämlich eine simple Häufigkeitsanalyse aus. (Selbstverständlich solltest du einen "richtigen" Deutschen (bzw Englischen) Text nehmen, kein auf-die-Tastatur-gehacke)
Dass man dieses System auch auf binäre Daten übertragen kann (Bilder, Filme, Exe-Dateien etc.) sollte dir klar sein. Auch in diesen Dateien gibt es bestimmte Häufigkeiten und sowas ;)
Aber wie schon gesagt wurde: Der Profi auf dem Gebiet sitzt nicht vor diesem Unirechner hier... ;)

Delete - Mi 28.11.07 13:11

Echte Zufallsgeneratoren gibt es - den radioaktiven Zerfall!

Das One-Time-Pad ist das einzig bekannte Verschlüsselungsverfahren, das informationstheoretisch sicher ist und nicht entziffert werden kann, wenn bestimmungsgemäß der Schlüssel zufällig ist und nur einmal zur Verschlüsselung verwendet wird. Allein mit Kenntnis des Schlüssels kann der Geheimtext entschlüsselt werden.

Der Schlüssel wird permanent und fortlaufend erzeugt und über das Internet verbreitet.
Um ein Dokument zu entschlüsseln, braucht man den Schlüssel, der ab einem bestimmten Zeitpunkt über das Internet verbreitet worden ist. Den Schlüssel "auf Vorrat" zu empfangen und zu speichern ist "zur Zeit" nicht möglich, weil die Datenmenge zu gross ist. Man braucht also das verschlüsselte Dokument UND den Schlüssel, den SENDER und EMPFÄNGER gleichzeitig aus dem Internet beziehen, das heisst: Der SENDER informiert den EMPFÄNGER über eine RELATIV sichere Verbindung, dass der Schlüssel ab einem beliebigen Zeitpunkt gesendet wird. Bis ein Mithörer DIESEN Zeitpunkt herausgefunden hat, ist er unwiederbringlich verstrichen.

Delete - So 02.12.07 04:07

JayEff hat folgendes geschrieben:

Es ist ja eine Vorraussetzung (wie bereits weiter oben beschrieben), die Dateierweiterung zu verändern und eine kurze (ein paar wenige Bytes genügen) Information über die Original-Erweiterung in die verschlüsselte Datei zu schreiben. Dadurch wird Dir die offenbare Information über den Inhalt der Datei verwährt. Und selbst diese Haeder-Information würde mittels des Schlüssels codiert.

ABER: Da die codierte Datei einen wiederum eindeutigen Header (Länge und Position der Informationen) bezüglich der Original-Erweiterung erhält, ist mir klar, dass sie bezüglich des Headers wieder entschlüsselbar ist. Dadurch resultiert Deine Voraussetzung für ein Entschlüsseln des gesamten Rests. Angenommen ich würde ein Verschlüsselungsverfahren schreiben, welches öffentlich angeboten wird, dann hätte mein Programm absolut keine Chance gegenüber anderen Verschlüsselungs-Algorhythmen. Es ist faktisch kein Einweg-Verfahren.

Mir geht es aber nicht um ein öffentliches Verfahren. Mir geht es um einen rein privaten Ansatz - um theoretische Gedanken zur Verschlüsselung. Um die Möglichkeit der Verschlüsselung ohne Kenntnis des Schlüüsels außer mir (nehmen wir dieses Optimum mal bitte so an) zu erörtern. Wie sicher wäre ein solches Verfahren, wen eine weitere Person die Daten "unterwegs" kopiert und eigenhändig zu entschlüsseln versucht.

Also ich glaube Person 2 hätte keine Chance. Erst ein öffentlicher Algorhythmus, oder auch das Wissen über den zu erwartenden Inhalt würden eine Entschlüsselung mit Vignére-Chiffre möglich machen.

gispos - So 02.12.07 20:37

g1o2k4 hat folgendes geschrieben:

wenn der schlüssel unendlich lang ist, ist eine einfache verschiebeverschlüsselung das sicherste wo gibt !^^
siehe OTP (One-Time-Pad)

xor dagegen ist ein scheiß...nur 256 schlüssel, super leicht zu knacken.

ich hab hier nen programm geschrieben das mit xor verschlüsselte texte knacken kann...

Dann versuch mal diese Text-Datei zu entschlüsseln, und poste dein Resultat.

Bin gespannt
gruß gispos

Delete - So 02.12.07 20:39

g1o2k4 hat folgendes geschrieben:

xor dagegen ist ein scheiß...nur 256 schlüssel, super leicht zu knacken.

Wenn man es genau nimmt nur 2 Schlüssel. Denn digital ist's halt nur binär 0 und 1.

In Deinem Fall gehts Du sehr wahrscheinlich davon aus, dass die Daten nur mit einem einzigen Byte verschlüsselt werden. Aber mit folgender Variante wird's schon schwieriger.

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:

type
  TABuffer = Array[ 0..2047 ] of Byte;  // So kann ein Datenpaket aus einem Stream typisiert werden.
// ...
function Crypt
         ( const pBuffer : TABuffer, const pKey : WideString )
         : TABuffer;
var
  I01,
  I02  : Integer;
begin
  I01 := 0;
  for I02 := 0 to High( pBuffer ) do
  begin
    Result[ I02 ] := pBuffer[ I02 ] xor pKey[ I01 ];
    if I01 + 1 > Length( pKey ) then
      I01 := 0
    else
      Inc( I01 );
  end;
end;

ub60 - So 02.12.07 21:41

gispos hat folgendes geschrieben:

Dann versuch mal diese Text-Datei zu entschlüsseln, und poste dein Resultat.
bin gespannt
gruß gispos

Hallo gispos,

wenn ich das richtig sehe, hast Du Deine 71 Zeichen lange Textdatei mit einem genau so langen Passwort verschlüsselt, also mit einem anderen Text. Dein Schlüssel besteht aus Worten der Länge 3, 6, 5, 3, 2, 6, 6, ... (Wortlänge beginnend vom ersten Wort). An 59. Stelle endet der erste Satz des Passworts, dann beginnt ein neuer Satz.

Ehe ich weiter Zeit investiere, sag mir mal, ob ich richtig liege.

ub60

JayEff - Mo 03.12.07 16:30

g1o2k4 hat folgendes geschrieben:

wie ist das verschlüsselt ? ich hab nur schlüssellänge von einem byte implementiert also 2^8 bit. und jedes zeichen wird halt mit allen 256 schlüsseln "gexort".

Du hast behauptet, dass "xor" unsicher im Vergleich zu einer Verschiebung sei.
Was hindert mich daran, bei meinem OTP statt einer Verschiebung xor anzuwenden? In Delphi

Delphi-Quelltext

1:
2:
3:
4:

for i := 0 to length(text) - 1 do
begin
  code := code + (text[i] xor key[i]);
end;

Schätze, genau so hat er gearbeitet :nixweiss: Damit ist wohl deine Aussage

g1o2k4 hat folgendes geschrieben:

widerlegt, da xor keineswegs meine Schlüsselläge auf 2^8 Bit beschränkt ;)

Edit: Argumentiert man wie du, so hat eine Verschiebung nur 26 Schlüssel (Das Alphabet). Du bist offensichtlich von einer monoalphabetischen Verschlüsselung mit xor ausgegangen. Klar, dass monoalphabetische Verschlüsselungen im Vergleich mit polyalphabetischen im punkto Sicherheit weit unterlegen sind :nixweiss:

Edit2: In Ada nimmt man für Arrays auch die runden Klammern. :autsch: runde durch eckige ersetzt.
Edit3: Gnarr... length(text) - 1

Delete - Mo 03.12.07 17:45

g1o2k4: Mal optimal angenommen, Du verschlüsselst wirklich nur einen Text mit 2^8 bit. Gehen wir weiter davon aus, dass mir bekannt ist, in welcher Sprache Du den Text verfasst hast. Dann muss ich nicht unbedigt eine BruteForce-Attacke auf Deinen Text loslassen, die alle 2^8 Schlüssel auf Deinen Text anwendet, bis ich ihn lesen kann. In diesem absoluten "Idealfall" nehme ich Buchstabenhäufigkeiten zur Hand.

Es gibt Statistiken, welche darüber Aufschluss geben, in welcher Sprache welche Buchstaben wie oft im Durchschnitt innerhalb eines Textes vorkommen. Die kodierten Zeichen aus Deinem verschlüsselten Text werden nun ebenfalls nach deren Häufigkeit bestimmt. Und ich ersetzte in Deinem Text das Zeichen mit dem Buchstaben aus dem Alphabet, bei dem die Häufigkeit am am nahesten liegt. Fehler sind nicht ausgeschlossen, da einige Buchstaben im Mittel sehr nah beieinander liegende Werte des vorkommens haben. Je länger ein Text, desto höher ist jedoch die Trefferquote. In der Regel reicht dieses Verfahren aus, um einen Text teilweise entschlüsseln zu können. Fehlende Zeichen werden dann meietwegen Korrektur gelesen.

Dieses Verfahren ist nicht nur auf Sprachen, sondern auch auf digitale Daten anwendbar, sowie der Schlüssel im Idealfall 1 Byte lang ist und der zu erwartende Inhalt nach seinem Muster bekannt ist. Dieses Muster ist mit der Buchstabenhäufigkeit vergleichbar.

Eine genaue Erklärung zur Buchstabenhäufigkeit findest Du bei Wikipedia: :arrow: Wikipedia :: Buchstabenhäufigkeit [http://de.wikipedia.org/wiki/Buchstabenh%C3%A4ufigkeit]

ub60 - Mo 03.12.07 19:19

Luckie hat folgendes geschrieben:

g1o2k4 hat folgendes geschrieben:

xor dagegen ist ein scheiß...nur 256 schlüssel, super leicht zu knacken.

Bitte treffe keine Aussagen über Themen, von denen du keine Ahnung hast.

Da stimme ich Dir zu.

Luckie hat folgendes geschrieben:

Ist bei einer XOR-Verschlüsselung das Passwort mindestens genauso lang wie der Text, ist XOR absolut sicher.

Das stimmt nicht!! Deine Aussage ist nur richtig, wenn der Schlüssel aus zufällig erzeugten Daten zusammengesetzt ist, die untereinander keinerlei Zusammenhang haben. Einen Text mit einem anderen Text zu verschlüsseln, der genau so lang ist, ist keinesfalls sicher. Auch, wenn der Schlüsseltext nicht öffentlich bekannt ist (aber zumindest irgend einen Sinn hat).

ub60

gispos - Di 04.12.07 22:41

ub60 hat folgendes geschrieben:

wenn ich das richtig sehe, hast Du Deine 71 Zeichen lange Textdatei mit einem genau so langen Passwort verschlüsselt, also mit einem anderen Text. Dein Schlüssel besteht aus Worten der Länge 3, 6, 5, 3, 2, 6, 6, ... (Wortlänge beginnend vom ersten Wort). An 59. Stelle endet der erste Satz des Passworts, dann beginnt ein neuer Satz.

Ehe ich weiter Zeit investiere, sag mir mal, ob ich richtig liege.
ub60

Der Schlüssel ist 17 Zeichen lang und ergibt für mich einen Sinn.

Fast so wie JayEff schon vermutet hat:

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:

function XorString(aText, Key: String): String;
var 
  x,i: Integer;
begin
  x:= 1;
  Result:= aText;
  for i := 1 to length(text) do
  begin
    Result[i]:= Chr(Ord(aText[i]) XOR Ord(Key[x]));
    inc(x);
    If x > length(Key) then x:= 1;
  end;
end;

Und für x gehen da außer "inc" noch ganz andere Sachen!

Gruß gispos

g1o2k4 - Mi 05.12.07 16:25

Neurologic Scientist hat folgendes geschrieben:

bruteforce mit dictionary ist einfach zu implementieren, wozu ein verfahren benutzen das nur bei textlänge gegen unendlich (im idealfall) funktioniert. wenn du eine email hast die nur 5 zeilen lang ist, kannste das vergessen und bei bestimmten texten auch. z.b. gibt es je nach thema des textes auch verschiedene häufigkeiten die auftreten. da bräuchte man nen ganzen satz von häufigkeitswerten.

JayEff - Mi 05.12.07 16:34

g1o2k4 hat folgendes geschrieben:

gibt es je nach thema des textes auch verschiedene häufigkeiten die auftreten. da bräuchte man nen ganzen satz von häufigkeitswerten.

Es gibt Häufigkeitstabellen die auf ganze Sprachen passen und ...
...es gibt Ausnahmen. Es gibt ein französisches Buch, in welchem kein einziges Mal der Buchstabe 'e' vorkommt. Interessanter ist, es gibt eine deutsche Übersetzung, auf die dies zutrifft :)
Fügt man Neurologic Scientists Beschreibung ein "genügend langer Text" an, ist sie beinah (mit wirklich wenigen Ausnahmen) uneingeschränkt wahr. Je nach Text genügen 2-3 Sätze, um durch bestimmte Häufigkeitsanalysen auf die Lösung zu kommen... Ein Beispiel wären die häufigsten 2-Buchstaben-Kombinationen wie 'en' sowie das häufigste 3 buchstabige Wort 'die', nicht nur die Häufigkeiten der Buchstaben n>e>...r>s>t etc.

g1o2k4 - Mi 05.12.07 19:47

JayEff hat folgendes geschrieben:

g1o2k4 hat folgendes geschrieben:

gibt es je nach thema des textes auch verschiedene häufigkeiten die auftreten. da bräuchte man nen ganzen satz von häufigkeitswerten.

es gibt immer ausnahmen: „Natürlich gibt es erklärbare Differenzen: Ein von Zitaten strotzender zoologischer Text
über den Einfluss von Ozon auf die Zebras im Zentrum von Zaire wird eine andere
Häufigkeitsverteilung haben als ein Traktat über die amourösen Aventüren des Balthasar
Matzbach am Rande des Panamakanals.“

wenn man den sicheren weg gehn will nimmt man halt das wörterbuch.

ub60 - Mi 05.12.07 20:03

zongo-joe hat folgendes geschrieben:

wie heisst denn das Buch (und seine deutsche Übersetzung) ?

Bitte, so heißen Sie:

Georges Perec, 1969 "La disparition"
Eugen Helmlé, 1986 "Anton Voyls Fortgang"

Auch interessant (Text ohne e, i, a, u):

Zitat:

Ottos Mops

Ottos Mops trotzt
Otto: fort Mops fort
Ottos Mops hopst fort
Otto: soso

Otto holt Koks
Otto holt Obst
Otto horcht
Otto: Mops Mops
Otto hofft

Ottos Mops klopft
Otto: komm Mops komm
Ottos Mops kommt
Ottos Mops kotzt
Otto: ogottogott

Ernst Jandl

ub60 :lol:

alzaimar - Mi 05.12.07 21:20

g1o2k4 hat folgendes geschrieben:

xor dagegen ist ein scheiß...nur 256 schlüssel, super leicht zu knacken.

ich hab hier nen programm geschrieben das mit xor verschlüsselte texte knacken kann...
http://www.tictech.de/BLL/XorCrypt_Projektordner.rar

Dein Programm verstehe ich nicht... Man verschlüsselt doch nicht nur mit einer Zahl, sondern mit einem 'etwas längeren' Schlüssel...

Wenn ich einen Text mit dem um 3 Buchstaben verschobenen Vor- und Zunamen meiner Mutter verschlüssele (und die hat einen langen Namen), dürfte dein Programm nicht weit kommen, oder bin ich zu alt, um dein Programm richtig zu bedienen?

g1o2k4 - Mi 05.12.07 21:35

alzaimar hat folgendes geschrieben:

g1o2k4 hat folgendes geschrieben:

das projekt dient zur demonstration von symmetrischen verschlüsselungsverfahren und war eines von 2 projekten zu meiner bll.
es ist richtig, dass man nicht nur mit einem 1 byte schlüssel verschlüsselt, man könnte das programm natürlich noch erweitern, wäre kein großer aufwand, aber eine hohe rechenzeit wäre die folge....
vorrausgesetzt der name deiner mutter steht in der wordlist müsste das programm es schaffen, solange du halt jeden buchstaben des namens mit demselben schlüssel verschlüsselst.

g1o2k4 - Mi 05.12.07 23:39

alzaimar hat folgendes geschrieben:

Das dachte ich mir.... Ein Schlüssel mit -sagen wir- 47 (Primzahl, weiss auch nicht wieso) Zeichen sollte doch ziemlich sicher sein.

ja ist es aber es reichen schon 12 zeichen von 26 möglichen, also beispielsweise nur groß oder kleinbuchstaben. daran rechnet man schon 100jahre mit nem guten desktop pc.
das sind 12^26 möglichkeiten

hier sind auch noch andere werte zu finden.
http://www.1pw.de/brute-force.html#n26

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!