BITTE hilfe! erster byte wird falsh entschlüsselt

lk

Also, die grundidee war ja genau, dass es ja nicht 'in - in' ist, sondern 'in - out', und dazu noch 'in - out[-1]'. Leider macht dieses '-1' den ersten byte falsh...

SeppJ, könntest du das mit der attacke bitte machen? Es würde mir helfen...

Danke im voraus

SeppJ

Kannst du einen langen verschlüsselten Text posten? Und sagen in welcher Sprache der Text ist? Da die Verschlüsselung nicht ganz trivial ist, werden wohl mehrere Dutzend kb Text nötig sein. Nimm irgendeinen Wikipedia-Artikel über Popkultur, die sind gerne mal 50.000 und mehr Wörter lang.

lustig hat übrigens Recht, dass es bei out[i]=tab[in[i]][in[i-1]] einfach wäre. Das ist auch das, woran ich gedacht hatte. Die Methode die du eigentlich hast, ist schon viel schwieriger(aber natürlich auch nicht sicher).

Wenn du das hier öffentlich postest, fühlen sich sicher auch andere Leute angespornt, sich daran zu Versuchen. Mach am besten einen neuen Thread auf in dem du nochmal dein Verfahren erklärst (in der Kryptographie geht man davon aus, dass der Feind das Verfahren kennt, bloß nicht den Schlüssel) und dazu aufrufst, den Text zu entschlüsseln. Wenn der verschlüsselte Text sehr lang sein sollte, speicher ihn irgendwo extern und setz einen Link.

lk

Verschlüsselter text über die *** (Deutsch): http://www.filefront.com/15854593/b.txt.trf

Oder sollte ich doch noch einen neuen Topic aufmachen ?

Da bin ich mal gespannt. (wer's entschlusseln kann, bitte sagen über wen das ist)

SeppJ

Also ich hab's gelesen und werde es mal probieren. Aber ich habe natürlich keine Zeit, das sofort zu machen. Gib mir ein paar Tage. Ist jetzt eigentlich das erste Zeichen richtig? Woran lag es denn?
Ist garantiert, dass auf der Diagonalen jeder Wert nur einmal vor kommt?

lk

Nein, das erste zeichen ist immer noch falsh. Und auf den Diagonalen können rgendwelche werte liegen, die auch X-mal vorkommen.
Ich find's ein bisschen schade, das du erst in ein paar tagen zeit hast. Ich werde es eben nochmal posten...

SeppJ

lk schrieb:

Nein, das erste zeichen ist immer noch falsh. Und auf den Diagonalen können rgendwelche werte liegen, die auch X-mal vorkommen.
Ich find's ein bisschen schade, das du erst in ein paar tagen zeit hast. Ich werde es eben nochmal posten...

Einen Ansatz habe ich:
Erstmal die absolute Verteilung jedes Zeichens. Dies sieht wie zu erwarten sehr gleichverteilt aus:
http://yfrog.com/28onefoldp

Aber jetzt kommt mein Ansatz: Ich gucke nicht nach der absoluten Verteilung, sondern ich gucke nach, wie oft ein Zeichen nach einem bestimmten anderen Zeichen kommt. Damit kriege ich 256 Graphen und die sehen dann überhaupt nicht mehr gleichverteilt aus. Hier ein Beispiel für einen davon:
http://yfrog.com/2stwofoldp

Man sieht ganz deutlich, dass im Originaltext nicht alle 256 ASCII-Zeichen vorkommen, denn dort benutzt du nur 2x26 Buchstaben, eventuell 10 Ziffern und ein paar Satzzeichen. Und man sieht ganz deutlich, dass nicht alle Zeichen gleich oft vorkommen.

Der Grundgedanke beim weiteren Vorgehen ist klar: Jetzt kann ich die Häufigkeit von Buchstaben in der deutschen Sprache nehmen und die häufigen Buchstaben mit ziemlich hoher Sicherheit richtig raten. Dies gibt mir schonmal viele der Einträge aus deiner Schlüsseltabelle. Außerdem kann ich damit schonmal die häufigsten Buchstaben vom Text wiederherstellen, Leerstellen wahrscheinlich auch, weil die auch recht häufig sind. Dann kann ich anfangen einzelne Wörter zu raten. Wer jemals Glücksrad gesehen hat weiß, wie weit man alleine mit den 5 häufigsten Konsonanten und einem Vokal kommt. Und wahrscheinlich werde ich mehr als einen Vokal haben, das macht die Sache noch einfacher. Jedes erratene Wort gibt mir weitere Einträge in der Tabelle. Damit kann ich dann wieder an anderer Stelle Buchstaben entschlüsseln. Das gibt mir wieder mehr Wörter die ich raten kann. Dies wird fortgeführt, bis ein ausreichender Teil des Textes rekonstruiert ist.

Ich denke, vor allem das zweite Bild dürfte dir klarmachen, dass dieser Ansatz prinzipiell funktionieren wird. Die Unterschiede sind ja schon ziemlich deutlich. Und das ist bei allen 256 Bildern so, ich habe nicht extra eines rausgegriffen, das besonders auffällig ist.

lk

Heiliger bimbam, da muss viel dran geändert werden :p Danke
Und, wo hast du die graphen hergekriegt ?

SeppJ

Simples Analyseprogramm, in wenigen Minuten selbst geschrieben:

#include<iostream>
#include<fstream>
#include<vector>
#include<sstream>
#include<string>
using namespace std;

int main()
{
  ifstream in;
  in.open("b.txt.trf",ios::binary);
  vector<vector<int> > count(256, vector<int>(256,0));
  char c, last;
  in.get(last);
  while (in.get(c)) 
    {
      ++count[static_cast<unsigned char>(last)][static_cast<unsigned char>(c)];
      last=c;
    }
  for (int i=0; i< 256;++i) {
    ofstream out;
    stringstream name;
    name << i;
    out.open(name.str().c_str());
    for (int j=0; j<256; ++j)
      out <<j<<" " << count[i][j]<<endl;
    out.close();
  }
}

lustig

lk schrieb:

Nein, das erste zeichen ist immer noch falsh. Und auf den Diagonalen können rgendwelche werte liegen, die auch X-mal vorkommen.

Das heisst, dass die Verschluesselung des ersten Zeichens nicht wirklich funktioniert (nicht umkehrbar ist). Extrembeispiel: Alles 1 auf der Diagonale. Das erste Zeichen wird immer 1 sein, unabhaengig davon was du verschluesselst.
Setze doch einfach in[-1] auf irgendetwas bekanntes, z.B. 'A'. Dann machst du:

char startingValue='A';
out[0]=tab[in[0]][startingValue];

Das sollte das Problem loesen. Wenn ich mal Zeit habe, versuche ich mich auch an dem verschluesselten Text :).

lk

SeppJ, giebt es denn auch andere methoden, zb verschlüsselte Binärdateien ohne die tabelle zu entschlüsseln? Wenn ja, könntest du die sagen ? (Wenn nein, reicht es aus die bits to verschieben, oder?)

SeppJ

lk schrieb:

SeppJ, giebt es denn auch andere methoden, zb verschlüsselte Binärdateien ohne die tabelle zu entschlüsseln? Wenn ja, könntest du die sagen ? (Wenn nein, reicht es aus die bits to verschieben, oder?)

Ich verstehe die Frage nicht. Meinst du, ob es möglich ist, auch Dateien zu entschlüsseln, die keine menschliche Sprache enthalten? Ja, sofern man eine ungefähre Vorstellung vom Inhalt hat. Es gibt immer Muster.

Und hier noch ein anderer Ansatz:
Dein Schlüssel hat höchstens 255*255*255 Kombinationen, das sind ungefähr 16 Millionen. Davon sind sehr viele nicht gültig, weil nur solche gelten, die ein korrektes Sudoku-Muster haben. Aber selbst wenn man es mit 16 Millionen Kombinationen zu tun hat: Ein kleiner Heimrechner kann 16 Millionen Schlüssel in einigen Minuten bis wenigen Stunden durchprobieren, je nach Geschwindigkeit und Länge des Textes. Ich könnte mir vorstellen, deinen Text mit solch einem Verfahren zu knacken, falls sich die Wortraterei als zu mühsam erweisen sollte.

lk

Nein. Du würdest es ja nach der anzahl der buchstaben oder so machen, aber wenn es kein text wäre, sondern eine binärdatei, dann würde dies ja nicht wirklich funktionieren. Würde es auch ausreichen - bei normalen texten - die bits jeweils for der verschlüsselung zu verschieben ? Daduch würde dann der text verwischt, und aus den danach verschlüsselten daten könnte man nicht mehr die anzahl der buchstaben bestimmen.
`

1 2 3 4 5 6 7 8

2 3 4 5 6 7 8 1

3 4 5 6 7 8 1 2

4 5 6 7 8 1 2 3

5 6 7 8 1 2 3 4

6 7 8 1 2 3 4 5

7 8 1 2 3 4 5 6

8 1 2 3 4 5 6 7

`

Hast du noch Ideen, wie man dies entschlüsseln könnte ? (ich nehme mich mal heute oder morgen an dieses bit-shifting)

lustig

SeppJ schrieb:

Dein Schlüssel hat höchstens 255*255*255 Kombinationen, das sind ungefähr 16 Millionen.

Hmm, da ist dir aber ein kleiner (*hust*) Fehler unterlaufen. Eigentlich waere es
(256*256)^256. Eine etwas kleinere Abschaetzung waere 256!*256, was immer noch ca. groesser als 10^500 ist...

SeppJ

lk schrieb:

Würde es auch ausreichen - bei normalen texten - die bits jeweils for der verschlüsselung zu verschieben ? Daduch würde dann der text verwischt, und aus den danach verschlüsselten daten könnte man nicht mehr die anzahl der buchstaben bestimmen.

Ich verstehe nicht, wo der Unterschied sein soll, wenn du alles bloß verschiebst.

Hast du noch Ideen, wie man dies entschlüsseln könnte ?

Selbst wenn ich einsähe inwiefern mein anderer Ansatz nicht funktionieren sollte: Ich bin nicht einmal ansatzweise ein Kenner von Entschlüsselungsverfahren. Ich habe einfach nur den Thread gelesen und mir gedacht "Da fällt ja selbst mir ein Angriff ein" und habe Spaß daran, das Verfahren in der Praxis zu überprüfen. Wenn ich mich mit Kryptographie auskennen würde, wäre ich in der Lage die konzeptionellen Schwächen zu erkennen und gezielt auszunutzen. Wahrscheinlich würde sogar ein sehr viel kürzerer Text ausreichen als der den du hochgeladen hast.
Das es konzeptionelle Schwächen des Verfahrens geben muss ist klar, da du kein mathematisches Konzept vorweisen kannst, warum das Verfahren etwas taugen sollte. Dass du zufällig etwas brauchbares gefunden haben solltest, ist sehr sehr unwahrscheinlich. Kryptographie denkt man sich nicht mal eben aus, Kryptographie entwickelt man.

lustig schrieb:

SeppJ schrieb:

Dein Schlüssel hat höchstens 255*255*255 Kombinationen, das sind ungefähr 16 Millionen.

Hmm, da ist dir aber ein kleiner (*hust*) Fehler unterlaufen. Eigentlich waere es
(256*256)^256. Eine etwas kleinere Abschaetzung waere 256!*256, was immer noch ca. groesser als 10^500 ist...

Ups, hast natürlich Recht. Also Brute-Force ist wohl doch nichts.

lk

SeppJ schrieb:

lk schrieb:

Würde es auch ausreichen - bei normalen texten - die bits jeweils for der verschlüsselung zu verschieben ? Daduch würde dann der text verwischt, und aus den danach verschlüsselten daten könnte man nicht mehr die anzahl der buchstaben bestimmen.

Ich verstehe nicht, wo der Unterschied sein soll, wenn du alles bloß verschiebst.

Wenn ich die daten vor dem verschlüsseln mit einer immer-gleichen methode verändere, die daten dann aber verschlüssele, kann man die immer-gleiche veränderung nicht vor dem entschlüsseln rückgängig machen. Somit kann man auch nicht auf die Buchstaben kommen, oder so. Auf jeden Fall aber würde das cracking-Verfahren von dir wegfallen (ein Schritt in der 'Kryptographie-Entwicklung' :p ).

(Kennt jemand vielleicht jemanden, der sich mit so etwas auskennt, und helfen könnte?)

SeppJ

lk schrieb:

Wenn ich die daten vor dem verschlüsseln mit einer immer-gleichen methode verändere, die daten dann aber verschlüssele, kann man die immer-gleiche veränderung nicht vor dem entschlüsseln rückgängig machen. Somit kann man auch nicht auf die Buchstaben kommen, oder so. Auf jeden Fall aber würde das cracking-Verfahren von dir wegfallen (ein Schritt in der 'Kryptographie-Entwicklung' :p ).

Eine monoalphabetische Veränderung bringt gar nichts.

(Kennt jemand vielleicht jemanden, der sich mit so etwas auskennt, und helfen könnte?)

Wenn dir jemand reicht, der sich ein paar Stunden mit dem Thema auseinandergesetzt hat: Mitlerweile ich.
Also: Was hast du vor?

lk

Also, ich will natürlich den Algorythmus sicher machen, gegen diese ganzen angriffs-Methoden. Ich habe vor, immer jeweils eine angriffs-Methode herauszufinden, und den Algorythmus entsprechend umändern, sodass er sicher gegen sie ist. Leider habe ich nicht viel Ahnung auf diesem Gebiet, aber man lernt ja das ganze Leben durch...

DocShoe

Wenn du schon einen eigenen Verschlüsselungsalgorithmus bauen willst (warum kannst/darfst du keinen fertigen benutzen?) kannst du dir auf dieser Seite mal einen anschauen, der sowohl sicher als auch einfach zu implementieren ist:

Solitaire

SeppJ

Ok, ich habe mich in den letzten Tagen mal ein bisschen mit Kryptoanalyse beschäftigt und kann dir sagen, was an deinem Verfahren nicht stimmt:

Dein Verfahren ist knackbar durch Frequenzanalyse, wie ich demonstriert habe (auch wenn ich nicht den Nerv habe das wirklich bis zum Ende durchzuziehen). Das ist eine prinzipielle Schwäche deines Verfahrens, da es sich um ein ersetzungsverfahren mit einer begrenzten Zahl an Alphabeten handelt. Es ist bekannt, welches Alphabet für welches Zeichen verwendet wurde, denn das vorherige Zeichen bestimmt das ALphabet. Dadurch ist es knackbar mit einer Frequnzanalyse, nur dass man es mit einer großen Zahl an Alphabeten zu tun hat.

Was könntest du dagegen tun? Mach die Wahl des Alphabets nicht vom vorherigen Zeichen, sondern von einem anderen Schlüsselwort abhängig.

Problem: Auch dieser Trick ist alt bekannt und längst analysiert: Man berechnet dann den Koinzidenzindex und kann so die Schlüssellänge erraten. Dann hat man es wieder mit einer bekannten Zahl an Alphabeten zu tun und kann auf diesen wieder eine Frequenzanalyse machen.

Was man dagegen tun könnte, ohne dein Verfahren grundlegend umzukrempeln, weiß ich nicht. Man kann es natürlich immer eine Stufe komplizierter werden lassen ,indem du den Schlüssel noch alternieren lässt, aber das ist keine prinzipielle Lösung und vergrößert nur die Zahl der Nachrichten, die ein Angreifer mitlesen muss, bevor er den Code angreifen kann.

Eine weitere Schwäche: Fallt dem Angreifer eine verschlüsselte Nachricht in die Hände, deren Quelltext er kennt, kann er ganz einfach den Schlüssel berechnen und somit alle anderen Nachrichten entschlüsseln, die mit dem gleichen Schlüssel verschlüsselt wurden. Selbst wenn man nur Teile der Nachricht kennt (z.B. es geht mit einer Anrede los, oder endet mit dem Wetterbericht), kann man schon einiges an Aussagen über den Schlüssel machen. Wenn man dann einige Teile des Schlüssels sicher kennt, kann man den Rest erraten. Auch dies ist eine prinzipielle Schwäche, die nicht durch einfache Abänderung des Verfahrens behoben werden kann.

Der Schlüsselaustausch ist eine weitere Schwachstelle. Der Schlüssel muss irgendwie von A nach B gelangen und darf dabei nicht abgehört werden. Dies ist eine prinzipielle Schwäche aller symmetrischen Verschlüsselungsverfahren. Dagegen helfen asymmetrische Verfahren (zumindest zum Austausch des Schlüssels), die grundsätzlich anders funktionieren als dein Verfahren.

lk

Also, über die Asymetrischen Verschlüsselungsmethoden habe ich mich auch schon informiert, leider habe ich nirgends etwas gefunden wie die dinger funktionieren.
Wenn ihr meint, das Verfahren sei nicht mehr zu retten, werde ich's an etwas anderem versuchen, was aber schade wäre...
Danke dir, SeppJ, dass du mir so fiel geholfen hast