Verschlüsselungs-schleife:

out[0] = tab[in[0]] [in[0]];
for (size_t int i = 1; i<length; i++)
{
	out[i] = tab[in[i]] [out[i-1]];
}

Entschlüsselungs-schleife:

for (size_t i = 0; i < 256; ++i) // hier müsste irgenwo der fehler sein
{
        if (in[0] == tab[i][i])
        {
            out[0] = i;
        }
}
for (size_t i = 1; i < n; ++i) // rest entschlüsseln, funktioniert
{
	size_t spaltennummer = in [ i - 1 ];

	size_t j = 0;
	for (; j < 256; ++j)
        {
		if (tab[j][spaltennummer] == in[i])
 			break;
	}
	out[i] = j;
}

Bitte bitte helft

edit: Das dein Algorithmus nicht sicher ist, dürfte dir aber klar sein, oder? Selbst mir würde spontan ein erfolgsversprechender Angriff^* einfallen und ich bin nun wirklich nicht sehr erfahren auf dem Gebiet.

^*: Über das statistische Vorkommen von aufeinanderfolgenden Zeichenfolgen im verschlüsselten Text.

Wenn eine attacke einfach wäre, was müsste ich ändern ?

src = in ( = inp )
out = dest

Dann bleibt die Frage, ob auf der Diagonalen jedes Zeichen genau einmal vorkommt. Ist dies nämlich nicht so, geht das Verfahren schief.

Wenn eine attacke einfach wäre, was müsste ich ändern ?

Einen von Experten entwickelten und von Mathematikern bewiesenen Algorithmus verwenden.

Ist eigentlich garantiert, dass die Diagonale alle Werte zwischen 0 und 255 enthält? Das ist aus deiner Beschreibung nicht ganz klar.

Ich wuerde auch darauf tippen, dass das der Fehler ist.

Zur Sicherheit: Wenn du dir selber einen Algorithmus ausdenkst, ist der meistens nicht "sicher". Es schwer eine gute Verschluesselung zu finden... aber das soll dich nicht davon abhalten es zu versuchen. Es macht ja trotzdem Spass (und es macht auch Spass die Schwaechen zu suchen). Wenn du dich fuer Verschluesselung interessierst, kann ich dir das Buch "The Code Book" von Simon Singh empfehlen.

@SeppJ Kannst du mir einen Tipp fuer den erfolgsversprechenden Angriff geben? Wenn er out[i]=tab[in[i]][in[i-1]] verwenden wuerde, waere es simpel. Aber bei out[i]=tab[in[i]][out[i-1]] sehe ich es gerade nicht... Aber es kann ja nicht so schwierig sein ;).

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

Danke im voraus

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.

Oder sollte ich doch noch einen neuen Topic aufmachen ?

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

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.

#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();
  }
}

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

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.

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)

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

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

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?

Solitaire

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.

Schau dir für ein sehr gebräuchliches Beispiel mal RSA an. Dieses basiert auf zwei mathematischen Problemen. Erstens die Leichtigkeit zwei Primzahlen zu finden und zu multiplizieren, aber die Schwierigkeit eine Zahl in zwei Primfaktoren zu zerlegen. Zweitens die Schwierigkeit die Eulerfunktion einer Zahl ohne Kenntnis von deren Primfaktoren zu berechnen.

Da asymmetrische verfahren recht Rechenaufwändig sind, wird häufig nur ein Schlüssel für ein Blockchiffre damit übertragen. Du kannst dir ja auch mal die gängigen Blockchiffres angucken. Diese sind (relativ) sicher, sofern man den Schlüssel sicher übertragen kann. Für simple Blockchiffres gibt es Angriffe, die neueren sind noch nicht genau erforscht, gelten aber (bisher) als sicher. Die moderneren Verfahren sind aber teilweise nicht ganz einfach zu implementieren.

Ich würde für den Anfang mal das schon vorgeschlagene Solitaire als Hauptchiffre implementieren und RSA als Übertragungsweg für den Schlüssel. Beide sind relativ einfach umzusetzen (zumindest wenn du für RSA eine Bibliothek für große Zahlen benutzt). Und das ist dann schon so sicher, dass es sich eher lohnt, einen unkonventionellen Angriff (also Überredung, Wanzen, Erpressung, Folter) zu starten, anstatt sich an dem Verschlüsselungsverfahren selbst die Zähne auszubeißen.