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:


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

Super. Gibt es die Delphi-Tags schon länger und ich habe es nur nie gemerkt? Oder seit wann?

Moin!

Neurologic Scientist hat folgendes geschrieben:

Super. Gibt es die Delphi-Tags schon länger und ich habe es nur nie gemerkt?

Och, die gibt´s schon ein paar Tage...

cu
Narses

Neurologic Scientist hat folgendes geschrieben:

Super. Gibt es die Delphi-Tags schon länger... ?

Ja, schon seeeeeeeeeeeeeeeeehr lange

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.

ub60

Die xor-Verschlüsselung ist absolut sicher, wenn du den absolut zufälligen Schüssel sicher übertragen kannst und er genauso lange ist wie der Text, und diesen auch nur ein mal brauchst (One-Time-Pad). Diese Voraussetzungen kannst du mithilfe der Quantenmechanik erreichen.

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.

@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)

Such mal in der 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.

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.

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

//Edit: 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!

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.

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.

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.

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

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.

Neurologic Scientist hat folgendes geschrieben:

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

Nein, Angebote gibts nur bei Frauen

Aber trotzdem Danke, dass Du mich verschonst.

Außerdem hab ich meine Krypto-Aufgabe für heute schon erledigt:www.delphi-forum.de/...78624&highlight=
Warum hat da eigentlich keiner mitgeknobelt?

ub60

Neurologic Scientist hat folgendes geschrieben:

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.

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 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...

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.

JayEff hat folgendes geschrieben:

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.

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.

Ich hab mal einen heißen Tip für euch.
Diffie-Hellman

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...
www.tictech.de/BLL/X...pt_Projektordner.rar